Automated verification of mri compatibility of active implantable medical device

ABSTRACT

A system may include a processor configured to automatically obtain magnetic resonance imaging compatibility information relating to compatibility of an active implantable medical device implantable in a patient with an MRI modality from at least two information sources. The processor may also be configured to automatically determine compatibility of the active implantable medical device with the magnetic resonance imaging modality based on the magnetic resonance imaging compatibility information.

This application is a continuation of U.S. patent application Ser. No.15/630,661, filed Jun. 22, 2017, which will issue as U.S. patent Ser.No. 10/004,910 on Jun. 26, 2018, which is a continuation of U.S. patentapplication Ser. No. 12/626,342, filed Nov. 25, 2009, now U.S. Pat. No.9,694,188, which claims the benefit of U.S. Provisional Application No.61/118,342, entitled “VERIFICATION OF MRI COMPATIBILITY OF ACTIVEIMPLANTABLE MEDICAL DEVICE,” and filed on Nov. 26, 2008. The entirecontents of each of these applications are incorporated herein byreference.

TECHNICAL FIELD

The disclosure relates to implantable medical devices and, moreparticularly, to magnetic resonance imaging (MRI) compatibility ofimplantable medical devices.

BACKGROUND

Implantable medical devices may be used to deliver therapy to patientsto treat a variety of symptoms or conditions such as chronic pain,tremor, Parkinson's disease, epilepsy, depression, urinary or fecalincontinence, sexual dysfunction, obesity, or gastroparesis. Forexample, an implantable medical device may deliver neurostimulationtherapy via leads that include electrodes located proximate to thespinal cord, pelvic nerves, peripheral nerves, the stomach or othergastrointestinal organs, or within the brain of a patient. Otherexamples of implantable medical devices include implantable medicaldevices configured to deliver electrical stimulation for cardiactherapy, such as cardiac pacing, cardioversion/defibrillation,resynchronization, or the like.

In general, an implantable medical device may deliver electricalstimulation therapy in the form of electrical signals such as pulses orother waveforms via one or more electrodes carried by one or moreimplantable leads. Many implantable medical devices include metalliccomponents, such as a housing, conductors, electrodes, and the like. Forsome implantable medical devices, these metallic components may make amagnetic resonance imaging (MRI) procedure undesirable. For example, MRIimaging produces radio frequency (RF) energy that may interact with someof the metallic components of the implanted medical device.

SUMMARY

In general, the disclosure is directed to techniques for determiningwhether a patient having an active implantable medical device (AIMD)implanted in his or her body is a candidate for an MRI scan. Thetechniques may include determining whether the AIMD is compatible withan MRI scan. For example, the AIMD may be compatible with an MRImodality having particular characteristics such as, for example, acertain magnetic field strength.

In one aspect, the disclosure is directed to a system comprising aprocessor configured to automatically obtain MRI compatibilityinformation relating to compatibility of an AIMD implantable in apatient with an MRI modality from at least two information sources.According to this aspect of the invention, the processor is alsoconfigured to automatically determine compatibility of the AIMD with theMRI modality based on the MRI compatibility information.

In another aspect, the disclosure is directed to a method comprisingautomatically obtaining with a processor MRI compatibility informationrelating to compatibility of an AIMD implantable in a patient with anMRI modality from at least two information sources. According to thisaspect of the disclosure, the method further includes automaticallydetermining with the processor compatibility of the AIMD with the MRImodality based on the MRI compatibility information.

In an additional aspect, the disclosure is directed to acomputer-readable medium comprising instructions that cause a processorto automatically obtain MRI compatibility information relating tocompatibility of an AIMD implantable in a patient with an MRI modalityfrom at least two information sources. According to this aspect of thedisclosure, the computer-readable medium also comprises instructionsthat cause the processor to automatically determine compatibility of theAIMD with the MRI modality based on the MRI compatibility information.

In another aspect, the disclosure is directed to a system comprising aprocessor configured to automatically obtain MRI compatibilityinformation relating to compatibility of an AIMD implantable in apatient with an MRI modality from an external data server. According tothis aspect of the disclosure, the processor is configured toautomatically determine compatibility of the AIMD with the MRI modalitybased on the MRI compatibility information.

In an additional aspect, the disclosure is directed to a methodincluding automatically obtaining with a processor MRI compatibilityinformation relating to compatibility of an AIMD implantable in apatient with an MRI modality from an external data server. According tothis aspect of the disclosure, the method also includes automaticallydetermining with the processor compatibility of the AIMD with the MRImodality based on the MRI compatibility information.

In a further aspect, the disclosure is directed to a system comprising apatient information terminal that receives MRI compatibility informationfrom a patient. The MRI compatibility information comprises informationrelating to compatibility of an AIMD implantable in the patient and anMRI modality. According to this aspect of the disclosure, the systemalso includes a processor that automatically determines compatibility ofthe AIMD with the MRI modality based on the MRI compatibilityinformation.

In another aspect, the disclosure is directed to a method that includesreceiving MRI compatibility information from a patient via a patientinformation terminal. The MRI compatibility information comprisesinformation relating to compatibility of an AIMD implantable in thepatient and an MRI modality. According to this aspect of the disclosure,the method also includes automatically determining, with a processor,compatibility of the AIMD with the MRI modality based on the MRIcompatibility information.

In an additional aspect, the disclosure is directed to acomputer-readable medium comprising instructions that cause a processorto receive MRI compatibility information from a patient via a patientinformation terminal. The MRI compatibility information comprisesinformation relating to compatibility of an AIMD implantable in thepatient and an MRI modality. According to this aspect of the disclosure,computer-readable medium also comprises instructions that cause theprocessor to automatically determine compatibility of the AIMD with theMRI modality based on the MRI compatibility information.

In another aspect, the disclosure is directed to a system including anAIMD implantable in a body of a patient and a patient programmer for theAIMD. According to this aspect of the disclosure, the patient programmeris configured to obtain MRI compatibility information relating tocompatibility of the AIMD with an MRI modality.

In a further aspect, the disclosure is directed to a method comprisingobtaining from at least one of a memory of a patient programmer or amemory of an active implantable medical device (AIMD), via a patientprogrammer, magnetic resonance imaging (MRI) compatibility informationrelating to compatibility of an active implantable medical device (AIMD)with an MRI modality.

In another aspect, the disclosure is directed to a computer-readablemedium comprising instructions that cause a processor to obtain from atleast one of a memory of a patient programmer or a memory of an activeimplantable medical device (AIMD), via a patient programmer, magneticresonance imaging (MRI) compatibility information relating tocompatibility of an active implantable medical device (AIMD) with an MRImodality.

In some examples, the techniques described in this disclosure may beperformed using instructions stored on a computer readable medium thatcause a processor to perform the techniques.

The details of one or more examples are set forth in the accompanyingdrawings and the description below. Other features, objects, andadvantages of the disclosure will be apparent from the description anddrawings, and from the claims.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is a schematic diagram illustrating a system including animplantable medical device in the form of an implantable electricalstimulation system.

FIG. 2 is a functional block diagram illustrating various examplecomponents of an implantable electrical stimulation system.

FIG. 3 is a functional block diagram illustrating various examplecomponents of an external programmer, such as a patient programmer orclinician programmer, for use in programming parameters and retrievinginformation from an active implantable medical device.

FIG. 4 is a functional block diagram illustrating a system that may beused to determine compatibility of an AIMD and an MRI modality.

FIG. 5 is a flow diagram that depicts an example technique fordetermining compatibility of an active implantable medical device and anMRI modality.

FIG. 6 is a flow diagram illustrating another example of a technique fordetermining compatibility of an AIMD and an MRI modality.

FIG. 7 is a flow diagram illustrating another example of a technique fordetermining compatibility of an AIMD and an MRI modality.

FIG. 8 is a flow diagram illustrating another example of a technique fordetermining compatibility of an AIMD and an MRI modality.

DETAILED DESCRIPTION

In general, the disclosure is directed to techniques for determiningwhether a patient, and, more particularly, a patient having an activeimplantable medical device (AIMD) implanted in his or her body, is acandidate for an MRI scan. The techniques may include determiningwhether the AIMD is compatible with an MRI scan performed by aparticular type or class of MRI modality, or with particular settings ofthe MRI modality, that would be used to perform the MRI scan on thepatient. For example, the AIMD may be compatible with an MRI modalityhaving particular characteristics such as, for example, a certainmagnetic field strength or a magnetic field strength below a particularthreshold value. The techniques described in this disclosure, in someexamples, may include collecting data regarding the AIMD, thecompatibility of the AIMD with a particular MRI modality, operatingparameters of the MRI modality, and the like. In some examples, thetechniques also may include determining, based on the collected data,whether the AIMD is compatible with the MRI modality.

In some examples, the techniques described in this disclosure may becomputer-implemented in a computer device or system. As an example, thetechniques may be implemented via a computer user interface that guidesa user to collect pertinent information. For example, the user may be apatient in which the AIMD is implanted. Additionally or alternatively,the computer device or system may be configured to automatically storeand retrieve information that is relevant or useful in an MRIcompatibility determination for the patient. In some examples, thecomputer user interface may be realized at least in part by one or morecomputer-implemented media, executed by a processor, such as one or moreinteractive web pages presented by a web server and displayed to a user.The web pages may be configured to prompt a user, such as the patient, aclinician, a medical technician, or the like, to enter informationregarding the AIMD and, optionally, the MRI modality, or to retrieve theinformation from one or more servers or devices, which may be local orremote from the device that presents the computer user interface.

In other examples, the techniques described in this disclosure may beimplemented at least in part using written materials such as a poster orinstruction sheet that provides graphical and/or textual information toguide a user, such as a patient, clinician (e.g., a radiologist,referring physician, managing physician, or implanting physician),medical technician, MRI staff member, MRI facility scheduler, nurse, orthe like to gather the pertinent information regarding the AIMD and MRImodality. The written materials may be stored as computer-readable mediaand presented in soft copy form on a computer display. In some cases,the written materials may be interactive in the sense that the patientmay enter information, manipulate check boxes, advance through a menu orseries of user interface screens, or the like, to complete the processoutlined by the written materials. In some cases, the written materialsmay be a series of web pages that guide the user through the process,and permit entry of pertinent information. In other cases, the writtenmaterials may be hard copy forms that are used by the user during theMRI compatibility determination process. The use of a poster,instruction sheet or other written materials may be combined withcomputer-implemented media and methods for collecting, storing, andretrieving pertinent information. Hence, in some examples, the MRIcompatibility determination techniques described in this disclosure maybe performed in a hybrid system that includes both written materials andcomputer-implemented media.

An AIMD may be an active IMD (AIMD), for example, in the sense that itis electrically powered or controlled. AIMDs may include a variety ofdifferent types of devices such as, for example, neurostimulators,cardiac rhythm management devices, drug delivery devices, physiologicalparameter monitoring devices, fluid control devices such as a cerebralspinal fluid (CSF) shunts or valve devices, mechanical urinary or fecalincontinence devices, mechanical sexual dysfunction therapy devices, orthe like. In general, an electrical stimulation device in the form of aneurostimulator will be described for purposes of illustration.

In some examples, an AIMD may not be compatible with an MRI scan. Forexample, the magnetic field produced by an MRI modality during the MRIscan may induce a current or voltage in conductive portions of the AIMD.The induced current or voltage may cause electrically resistive andthermally conductive portions of the AIMD to increase in temperature,which could cause undesirable heating in tissue adjacent to the AIMD orcould interfere with operation of the AIMD. In other cases, a magneticfield produced by the MRI scan may cause one or more components of anAIMD to move from a normally implanted position. In these examples, itmay be desirable to determine whether the AIMD implanted in the patientis compatible with the MRI scan such that it is not susceptible to theissues described above. Hence, compatibility of the AIMD with aparticular MRI modality may refer to whether the AIMD is constructedsuch that it does not produce an undesired level of heating or such thatit maintains at least limited operation in the presence of an MRI fieldproduced by the modality.

However, in other examples, an AIMD may include one or more featuresthat facilitate compatibility with MRI modalities that produce certainmagnetic field strengths or magnetic field strengths below a thresholdvalue. For example, some AIMDs may be constructed with MRI safe (MRIS)or MRI conditionally safe (MRICS) hardware. MRIS hardware includeshardware that is confirmed to be safe when used with substantially anyMRI modalities operating with substantially any operatingcharacteristics. In contrast, MRICS hardware includes hardware that isconfirmed to be safe when used with certain, predetermined MRImodalities or certain, predetermined MRI scan parameters. In someexamples, MRICS or MRIS hardware may include lead conductorconfigurations that produce less heat in the presence of MRI energy,particularly when MRI energy is less than a prescribed level. MRICS orMRIS hardware also may include a thermally insulated outer housing ofthe AIMD, which may reduce undesirable heating of tissue adjacent to theouter housing. In each case, it may be important to verify MRICS or MRISstatus for an AIMD implanted in a patient before exposing the patient toenergy from an MRI modality.

As an illustration with or without MRIS or MRICS hardware, some AIMDs,for example, may be compatible with an MRI modality that produces amagnetic field having a certain magnitude. As an example, some AIMDs maybe compatible with MRI modalities that produce an MRI scan magneticfield strength equal to approximately 1.5 Tesla (T). In these examples,the techniques described in this disclosure may include identifying theAIMD as an AIMD that is compatible with an MRI scan that has a magneticfield with a certain magnitude, and identifying the MRI modality asproducing a magnetic field having a certain magnitude. In some examples,other operating parameters of an MRI modality may be identified andutilized to determine compatibility between an AIMD and an MRI modality.For example, some AIMDs may be compatible with an MRI modality thatproduces a magnetic field having a maximum magnitude that is less than athreshold value. In such examples, the techniques for determiningcompatibility between the AIMD and an MRI modality may includeidentifying the AIMD as an AIMD that is compatible with an MRI scan thathas a magnetic field with a maximum magnitude lower than a thresholdvalue, and identifying the MRI modality as producing a magnetic fieldhaving a maximum magnitude less than the threshold value. As anotherexample, some AIMDs may be compatible with an MRI modality that producesa specific absorption rate (SAR) of less than a threshold value, suchas, for example, 2.0 W/kg. In such examples, the techniques fordetermining compatibility between the AIMD and an MRI modality mayinclude identifying the AIMD as an AIMD that is compatible with an MRImodality that produces a SAR lower than a threshold value, andidentifying the MRI modality as producing a SAR that is less than thethreshold value.

In some examples, the techniques for determining whether a patienthaving a medical device implanted in his or her body is a candidate foran MRI scan may optionally include confirming that the AIMD is or is notcompatible with the MRI modality by determining the type of hardwareand/or software of the AIMD. The techniques described in this disclosurealso may optionally include determining a location in the patient atwhich the AIMD is implanted. In some examples, the techniques mayfurther optionally include testing the electrical impedance of one ormore leads (and/or lead extensions or lead adaptors, if present) thatmay be coupled to the AIMD to determine whether any of the leads aredamaged, which may cause the patient to not qualify for an MRI scan dueto increased risk.

In some examples, the AIMD may include an MRI conditionally safeoperating mode, and the techniques described in this disclosure mayinclude configuring the AIMD in the MRI conditionally safe operatingmode. In some examples, the MRI conditionally safe operating mode maycause the AIMD to suspend therapy delivery, but may maintain the AIMD ina low power state so that the AIMD does not accidentally deliver therapyto the patient during the MRI scan.

In some examples, the techniques may further include interrogating theMRI modality and determining whether the MRI modality is in the properoperating mode and the MRI scan parameters are safe for the AIMD. Thetechniques described in this disclosure may also include commencing theMRI scan when it is determined that the AIMD is compatible with the MRImodality. In some examples, the results of the techniques, e.g., thecollected MRI compatibility information and/or decisions made based onthe information, may be archived in a database or output by a computerto enable documentation of performance of the technique and the resultsof the technique. For example, it may be desirable to maintain a recordindicating that the compatibility determination technique was performed.In some cases, the record may indicate the scope of issues that wereconsidered and/or the number of tasks that were performed.

Some aspects of the techniques described in this disclosure may beperformed using instructions stored on a computer-readable medium andexecuted by one or more processors to carry out such techniques inconjunction with a computing system. Some aspects may be implemented inpart by written materials such as a poster or instruction sheet utilizedby a user to collect and/or record the pertinent information.Instructions executed by the processor may comprise software associatedwith an application program running on a computer or data server orassociated with one or more web pages presented on a computer andobtained from a web server. In either case, the software may present agraphical user interface to guide a user, such as a patient, clinician,medical technician, or the like to enter any of a variety of pertinentinformation to support the MRI compatibility determination.

In some examples, the instructions may cause the processor to retrieveat least some of the pertinent data from one or more devices, such asthe AIMD, a patient information terminal, a patient programmer, or oneor more data servers. In some examples, at least one of the one or moredevices may be external to the device that includes the processor. Inaddition, some of the devices, such as data servers, may be remote fromthe device that includes the processor. One or more data servers may bemaintained by the facility at which the MRI modality is located, by amanufacturer of the MRI modality, by a manufacturer of the AIMD, or by athird party, such as a third party that maintains compatibilityinformation and/or relevant design specification information for variousMRI modalities and various AIMDs. In some examples, a softwareapplication program or web page may be accessed on a computing devicethat is connected to a network. Network access may facilitate entry ofdifferent portions of the pertinent data by different users, or atdifferent devices, as well as sharing of information among differentdevices and users. In some examples, a processor may automaticallyretrieve MRI compatibility information from at least one informationsource that is external from the device in which the processor isincluded. For example, the processor may be contained in a patient orclinician programmer, and may automatically retrieve information fromthe AIMD, a patient information terminal, another programmer, and/or oneor more data servers, some of which may be remote in the sense that theyare located at a different location than the processor and accessedremotely over a network. In some examples, a processor may automaticallyretrieve MRI compatibility information from at least two informationsources, e.g., the AIMD, the patient information terminal, the patientprogrammer, and/or one or more data servers, and at least one of theinformation sources may or may not be a device in which the processor isincluded. The MRI compatibility information may include informationregarding an AIMD (AIMD information) and/or information regarding an MRImodality (MRI modality information).

In some examples, the patient may enter and/or retrieve some informationvia a patient information terminal. The patient information terminal mayinclude, for example, a computer executing a software program oraccessing a website, into which the patient may enter and/or from whichthe patient may retrieve MRI compatibility information prior to arrivingat the MRI facility. In other examples, the patient information terminalmay include a computer at the MRI facility that executes a softwareprogram or accesses a website into which the patient may enter and/orfrom which the patient may retrieve MRI compatibility information. Inother examples, a staff member of the MRI facility may enter and/orretrieve some information during registration of the patient at acomputing device associated with the MRI facility, e.g., based oninformation obtained from the patient over the telephone, or over otherelectronic communication media, such as email, web chat, videoteleconference, or the like. Hence, the patient information terminal maybe located at the MRI facility or elsewhere, or presented by a web pageor other computer interface presented by a computing device at alocation remote from the MRI facility. In some examples, an MRItechnician may enter and/or retrieve some of the information at acomputing device associated with the MRI modality. A clinical recordkeeper may enter and/or retrieve some of the information at anothercomputing device, e.g., to verify that the compatibility determinationwas performed or performed properly.

One or more processors associated with one or more computing devices mayautomatically determine whether the patient has an AIMD implanted in hisor her body that is compatible with the MRI modality utilized at the MRIfacility based on the collective information retrieved by theprocessor(s) or entered by users, such as the patient, the staff member,and/or the MRI technician. Alternatively, one or more processorsassociated with one or more computing devices may present informationbased on the information entered by various persons for verification bya user to determine whether the patient has an AIMD implanted in his orher body that is compatible with the MRI modality utilized at the MRIfacility. Hence, the actual compatibility determination may be madeautomatically by one or more computing devices without userintervention, may be rendered by a human user, or the computing systemmay generate a recommended compatibility determination for review andapproval by a human user.

In other examples, the techniques described in this disclosure may beperformed at least in part using a poster or instruction sheet thatguides a user through the process of collecting the pertinentinformation. For example, an instruction sheet may be followed by apatient to provide the pertinent information. As other examples, theinstruction sheet may be utilized by an MRI technician or other staffperson of the MRI facility to collect pertinent information from avariety of sources. The instruction sheet may further provide criteriathat enable the user to determine whether the AIMD implanted in thepatient is compatible with the MRI modality utilized by the MRIfacility.

The sources of information may include, for example, the patient, apatient ID card, AIMD compatibility documentation, a manufacturerwebsite, interaction with or information from a manufacturer employee,an MRI modality, a patient programmer or clinician programmer,interaction with or information from the patient's primary physician,information carried by the AIMD, or information stored by one or moredata servers (e.g., an MRI data server, and AIMD data server, or thelike). Information carried by the patient programmer, clinicianprogrammer, or AIMD may include electronic data indicating whether theAIMD is MRI compatible or conditionally MRI compatible, or may includedata that can be used to determine whether the AIMD is MRI compatible.

For example, the electronic data may be stored in memory in theprogrammer or AIMD and specify a manufacturer, model name or number,pertinent MRI compatibility specifications, or other information. Suchelectronic data may be obtained by wired or wireless communication withthe programmers or the AIMD. In some cases, the AIMD may further includeradio-opaque markers or codes that can be imaged, e.g., by fluoroscopy,to determine information similar to that described above.

In some examples, a patient programmer may be utilized by a patient oranother user, such as a MRI technician, to interrogate an AIMD implantedin the patient to retrieve information carried by the AIMD that ispertinent to compatibility of the AIMD with an MRI modality. Theinformation may be stored in memory of the AIMD, and may have beenprogrammed into memory of the AIMD at the time of implant, aftergathering of the MRI compatibility information by a device or systemdescribed in this disclosure, or after a change to the AIMD or anotherdevice implanted in the patient (e.g., after an impedance measurementindicates a lead failure). The patient programmer may retrieve the MRIcompatibility information from the AIMD upon receiving a command fromthe user to retrieve the MRI compatibility information or upon receivinga command from the user to determine whether the AIMD is MRI compatible.

Upon receiving such a command, the patient programmer may automaticallyretrieve the MRI compatibility information from the AIMD. In someexamples, the patient programmer may display the MRI compatibilityinformation to the user to allow the user to determine whether the AIMDis compatible with the MRI modality. In other examples, the patientprogrammer may automatically determine, based on the MRI compatibilityinformation, whether the AIMD is compatible with the MRI modality anddisplay the result to the user for verification, e.g., via a displayassociated with the programmer or another display that receives theresult from the programmer. In some examples, the patient programmer mayautomatically determine, based on the MRI compatibility information,whether the AIMD is compatible with the MRI modality and, if the AIMD iscompatible with the MRI modality, instruct the AIMD to enter an MRI safeoperating mode. Also, in some examples, the patient programmer may beconfigured to communicate MRI compatibility information or a MRIcompatibility determination result to another device such as a computingdevice used by MRI facility personnel or a computing device orcontroller associated with operation of the MRI modality.

As described above, the techniques described in this disclosure may beutilized to determine whether a patient having an AIMD implanted in hisor her body is a candidate for an MRI scan. FIG. 1 illustrates anexample patient 12 having an AIMD 14 implanted in his or her body. Whilepatient 12 is depicted as a human being in FIG. 1, patient 12 is notnecessarily a human being. For example, patient 12 may be anothermammal. AIMD 14 forms one part of a medical device system 10, which alsoincludes an external programmer 20. As shown in FIG. 1, system 10further includes a pair stimulation leads 16A, 16B implanted within apatient 12 and coupled to AIMD 14. Stimulation leads 16A, 16B may carryone or more electrodes through which AIMD 14 delivers stimulation to atarget tissue site within patient 12.

Although AIMD 14 is described in this disclosure primarily as animplantable neurostimulator, in other examples, AIMD 14 may compriseanother type of therapy device or may comprise an implantable monitoringor sensing device. For example, AIMD 14 may comprise an implantablecardiac rhythm management device that delivers at least one of pacingpulses, cardioversion shocks, or defibrillation shocks to cardiac tissueof patient 12, and which may or may not monitor a cardiac rhythm ofpatient 12. In other examples, AIMD 14 may comprise an implantable drugdelivery device or an implantable monitoring device, which monitors oneor more physiological parameters of patient 12 and may or may notdeliver therapy to patient 12. For examples in which the MRIcompatibility determination is made or aided by a patient programmer,the patient programmer may be configured, for example, for use by apatient in selecting at least some therapy parameters or programs.

In the case of an AIMD 14 comprising an implantable neurostimulator, forexample, a patient programmer may permit a patient to select particularneurostimulation therapy programs specifying parameters for delivery ofneurostimulation, such as electrical stimulation voltage or currentamplitude, pulse width, pulse rate, electrode configuration, duty cycle,or the like. The patient programmer may permit a patient to selectindividual programs, or groups of programs, or possibly adjust some ofthe parameters associated with the programs. In the case of animplantable drug delivery device, the patient programmer may permit apatient to select particular drug delivery programs, such as therapyschedules and associated dosage levels.

The patient programmer may be configured to permit the patient tocontrol or adjust only a limited subset of the therapy parameters,rather than all of such therapy parameters, e.g., for safety reasons orsimplicity in patient programmer operation. For example, the patientprogrammer may be configured to permit the patient amplitude, pulsewidth, or pulse rate adjustments to be made only within a limited range,or to permit only particular sets of electrode configurations to beselected by the patient. In contrast, a clinician programmer may beconfigured for use by a clinician or other caregiver, and permit aclinician to control or adjust a larger, and perhaps complete, set oftherapy parameters, relative to the limited set of parameters adjustablevia the patient programmer.

In some examples, AIMD 14 may comprise an MRI safe or an MRIconditionally safe device. An MRI safe device may include softwareand/or hardware features that result in AIMD 14 being compatible withsubstantially all MRI modalities and MRI scan parameters. An MRIconditionally safe device may include software and/or hardware featuresthat result in AIMD 14 being compatible with a more limited range of MRImodalities and/or MRI modality scan parameters. For example, a MRIconditionally safe device may be compatible with a limited range ofmagnetic field power levels or MRI radio frequency (RF) coil types. Ineither case, hardware features may include construction of a housing ofAIMD 14, leads 16, any lead extensions or lead adaptors used, and/orcircuitry within AIMD 14. These hardware features may be designed toreduce or minimize inductive heating of components of AIMD 14 or leads16 when exposed to a magnetic field generated by an MRI modality.Additionally or alternatively, the hardware or software features may bedesigned to reduce or minimize electromagnetic interference between themagnetic field generated by the MRI modality and operation of AIMD 14.

As shown in FIG. 1, leads 16A, 16B (collectively “leads 16”) areimplanted adjacent a spinal cord 18 of patient 12, e.g., for spinal cordstimulation (SCS) to alleviate pain. However, the techniques describedin this disclosure are applicable to systems including an AIMD 14coupled to leads implanted to target any of a variety of targetlocations within patient 12, such as leads carrying electrodes locatedproximate to spinal cord 18, pelvic nerves, peripheral nerves, thestomach or other gastrointestinal organs, or within the brain of apatient. In some examples, leads 16 may be coupled to lead extensions orlead adaptors.

In the example of FIG. 1, stimulation energy is delivered from AIMD 14to spinal cord 18 of patient 12 via one or more electrodes carried byaxial leads 16A and 16B implanted within the patient. In variousapplications, such as spinal cord stimulation (SCS), the adjacentimplantable leads 16 may have longitudinal axes that are substantiallyparallel to one another. Various combinations of electrodes carried bythe leads 16 may be used to deliver electrical stimulation, includingcombinations of electrodes on a single lead or combinations ofelectrodes on both leads. Also, in some examples, electrodes may becarried by paddle leads in which an array of electrodes may be arrangedin a two-dimensional pattern, e.g., as columns or rows of electrodes, ona common planar lead surface.

For leads or other electrode arrays, electrodes may be formed as any ofa variety of electrodes such as ring electrodes, segmented electrodes,needle electrodes, pad electrodes, or the like. In general, the term“electrode array” may refer to electrodes deployed on axial leads,paddle leads, or other lead configurations.

In the example of FIG. 1, leads 16 carry electrodes that are implantedadjacent to the target tissue of spinal cord 18. In particular, leads 16may be implanted in the epidural space adjacent spinal cord 18, andcoupled to AIMD 14. In the example of FIG. 1, stimulation energy may bedelivered to spinal cord 18 to eliminate or reduce pain perceived bypatient 12. However, the stimulator may be used with a variety ofdifferent therapies, such as peripheral nerve stimulation (PNS),peripheral nerve field stimulation (PNFS), deep brain stimulation (DBS),cortical stimulation (CS), pelvic floor stimulation, gastricstimulation, and the like. The stimulation may be configured toalleviate a variety of symptoms or conditions such as chronic pain,tremor, Parkinson's disease, epilepsy, urinary or fecal incontinence,sexual dysfunction, obesity, or gastroparesis. The stimulation deliveredby AIMD 14 may take the form of stimulation pulses or continuouswaveforms, and may be characterized by controlled voltage levels orcontrolled current levels, as well as pulse width and pulse rate in thecase of stimulation pulses.

The stimulation energy may be delivered via selected combinations ofelectrodes carried by one or both of leads 16. The target tissue may beany tissue affected by electrical stimulation energy, such as electricalstimulation pulses or waveforms. Such tissue may include nerves, nervebranches, smooth muscle fiber, and skeletal muscle fiber. In the exampleillustrated by FIG. 1, the target tissue is spinal cord 18. Stimulationof spinal cord 18 may, for example, prevent pain signals from travelingthorough the spinal cord and to the brain of the patient. Patient 12 mayperceive the interruption of pain signals as a reduction in pain and,therefore, efficacious therapy.

With reference to FIG. 1, a user, such as a clinician, physician orpatient 12, may interact with a user interface of external programmer 20to program stimulator 14 or retrieve from AIMD 14 information regardingoperation of stimulator 14. Programming of AIMD 14 may refer generallyto the generation and transfer of commands, programs, or otherinformation to control the operation of the AIMD 14. For example,programmer 20 may transmit programs, parameter adjustments, programselections, group selections, or other information to control theoperation of AIMD 14, e.g., by wireless telemetry. Parameter adjustmentsmay refer to initial parameter settings or adjustments to such settings.A program may specify a set of parameters that define stimulation. Agroup may specify a set of programs that define different types ofstimulation, which may be delivered simultaneously using pulses withindependent amplitudes or on a time-interleaved basis.

Programmer 20 may be a clinician programmer or a patient programmer. Anexample of a commercially available clinician programmer is theMedtronic N'Vision® Programmer Model 8840, marketed by Medtronic, Inc.,of Minneapolis, Minn. An example of a commercially available patientprogrammer is the Medtronic myStim® Programmer, marketed by Medtronic,Inc. In some cases, external programmer 20 may be a physician orclinician programmer if it is primarily intended for use by a physicianor clinician. In other cases, external programmer 20 may be a patientprogrammer if it is primarily intended for use by a patient. In general,a physician or clinician programmer may support selection and generationof programs or parameters by a clinician for use by AIMD 14. A clinicianprogrammer may permit a clinician to control or adjust a larger set oftherapy parameters than a patient programmer allows a patient to adjust.For example, a clinician programmer may allow a clinician to define newtherapy programs or therapy parameter sets, or to modify parameters ofan existing therapy program within a wide range, e.g., a parameter rangeaccessible by hardware and/or software AIMD 14. In contrast, a patientprogrammer may only allow a patient to select among predeterminedtherapy programs or to modify one or more therapy parameters within arange defined by the physician and programmed in the patient programmer.In some examples, a patient programmer may be configured to be portableand carried by patient 12 during a daily routine. In some examples, amedical device system 10 may include both a patient programmer and aclinician programmer, which may enable a clinician to program AIMD 14and/or the patient programmer and may allow patient 12 some control overhis or her therapy.

AIMD 14 may be implanted in patient 12 at a location minimallynoticeable to the patient. Alternatively, stimulator may be external topatient 12 and coupled to implanted leads via a percutaneous extension.For spinal cord stimulation (SCS), as an example, AIMD 14 may belocated, among other locations, in the lower abdomen, lower back, orother location to secure the stimulator. Leads 16 may be tunneled fromAIMD 14 through tissue to reach the target tissue adjacent to spinalcord 18 for stimulation delivery. At distal portions of leads 16 are oneor more electrodes (not shown) that transfer stimulation energy from thelead to the tissue. The electrodes may be electrode pads on a paddlelead, circular (i.e., ring) electrodes, surrounding the body of leads16, segmented electrodes arranged at different axial and rotationalpositions around a lead, conformable electrodes, cuff electrodes, or anyother type of electrodes capable of forming unipolar, bipolar ormultipolar electrode configurations. In general, segmented electrodesarranged at selected axial and rotational positions at the distal endsof leads 16 will be described for purposes of illustration.

In the example of FIG. 1, each of the electrode combinations specifies acombination of electrodes arranged along lengths of two or more leads.If each lead 16 includes four ring electrodes, then the leads can beviewed as having four axial positions or levels. For segmentedelectrodes, an electrode may occupy a rotational arc at a given axialposition of the lead. In some cases, the rotational arc may be similarto a portion of a ring electrode. For example, instead of a ringelectrode that extends 360 degrees around a lead body, three, separateninety degree segments could be provided to form three segmentedelectrodes at a given axial position along the length of the lead.Hence, two or more segmented electrodes may be provided at the sameaxial position but at different, non-overlapping rotational positions.Alternatively, a single segmented electrode could be provided at each ofmultiple axial levels. In general, in each case, a segmented electrodeor electrode segment may have a dimension that spans only a portion ofthe circumference of the lead, unlike a ring electrode which generallyextends around the entire circumference.

An electrode combination may include combinations of electrodes on thesame lead or multiple leads, as well as one or more electrodes on ahousing of AIMD 14 in some cases. In each case, some electrodes in anelectrode combination may form anodes while other electrodes formcathodes, establishing paths for flow of electrical stimulation currentrelative to an anatomical target such as spinal cord nerve tissue at adesired position on the spinal cord. As an example, for SCS, stimulationmay be delivered in the vicinity of the T7, T8 and T9 vertebrae,although other positions on the spinal cord are possible. In acurrent-based system, electrodes may be selected to form anodes orcathodes coupled to regulated current sources and sinks, respectively.

FIG. 2 is a functional block diagram illustrating various components ofan AIMD 14. In the example illustrated in FIG. 2, AIMD 14 includes aprocessor 24, memory 26, stimulation generator 30, telemetry circuit 28,and power source 32. Memory 26 may store instructions for execution byprocessor 24, stimulation therapy program data, sensor data, operationaland status data, and any other electronic information regarding therapyor patient 12. Such information in memory 26 may assist in determiningwhether AIMD 14 is compatible with an MRI modality, as described infurther detail below. Stimulation program data may include stimulationparameters transmitted from programmer 20, as well as programs definedby such parameters, and program groups. Some data may be recorded forlong-term storage and retrieval by a user. Memory 26 may includeseparate memories for storing different types of data.

In some examples, memory 26 also may store information pertinent tocompatibility of AIMD 14 with an MRI modality. For example, memory 26may store a date on which AIMD 14 and/or leads 16 were implanted inpatient 12, a date on which any revision was made to AIMD 14 and/orleads 16, a presence of another IMD implanted in patient 12, or a nameand/or phone number of a physician who implanted AIMD 14 or manages careof patient 12. In some examples, memory 26 may store a manufacturer ofAIMD 14 and contact information for the manufacturer, an identifier ofAIMD 14 and/or leads 16, such as a serial number, model number,registration number, name, or the like, and/or a magnetic fieldmagnitude to which AIMD 14 can be exposed. Additionally oralternatively, memory 26 may store information regarding an implantlocation of AIMD 14 and/or leads 16, an indication of the presence of anabandoned, broken, or damaged lead 16, or an impedance of one or more ofleads 16 (and, if present, lead extensions or adaptors).

Processor 24 controls stimulation generator 30 to deliver electricalstimulation via electrode combinations formed by electrodes in one ormore electrode arrays. For example, stimulation generator 30 may deliverelectrical stimulation therapy via electrodes of one or more leads 16,e.g., as stimulation pulses or continuous waveforms. Stimulationgenerator 30 may include stimulation generation circuitry to generatestimulation pulses or waveforms and switching circuitry to switch thestimulation across different electrode combinations, e.g., in responseto control by processor 24. In particular, processor 24 may control theswitching circuitry on a selective basis to cause stimulation generator30 to deliver electrical stimulation to selected electrode combinationsand to shift the electrical stimulation to different electrodecombinations. Alternatively, in some embodiments, stimulation generator30 may include multiple current or voltage sources to control deliveryof stimulation energy to selected combinations of electrodes carried byleads 16.

Electrode combinations and other parameters associated with differenttherapy programs may be represented by data stored in a memory location,e.g., in memory 26, of AIMD 14. Processor 24 may access the memorylocation to determine the electrode combination for a particular programand control stimulation generator 30 to deliver electrical stimulationvia the indicated electrode combination. Each program may specify a setof parameters for delivery of electrical stimulation therapy. As anexample, a program may specify electrode combination, electrodepolarities, current or voltage amplitude, pulse rate and pulse width.Additional parameters such as duty cycle, duration, and deliveryschedule also may be specified by a therapy program.

Using an external programmer, such as programmer 20, a user may selectindividual programs for delivery on an individual basis, or combinationsof programs for delivery on a simultaneous or interleaved basis. Inaddition, a user may adjust parameters associated with the programs. Theprograms may be stored in memory 26 of AIMD 14. Alternatively, theprograms may be stored in memory associated with external programmer 20.In either case, the programs may be selectable and adjustable to permitmodification of therapy parameters. In some examples, programmer 20 maybe a patient programmer, which may allow patient 12 to select amongprograms programmed by a clinician and stored in a memory of AIMD 14 orthe patient programmer. Additionally or alternatively, a patientprogrammer may allow patient 12 to adjust therapy parameters within arange determined by a clinician and stored in memory of the patientprogrammer or AIMD 14. In addition, a physician programmer may permitgeneration of new programs, which may be loaded into memory 26, andadjustment of parameters associated with existing programs.

Upon selection of a particular program or program group from memory 26,processor 24 may control stimulation generator 30 to deliver stimulationaccording to the programs in the groups, e.g., simultaneously or on atime-interleaved basis. A group may include a single program or multipleprograms, each of which specifies an electrode combination. Again, theelectrode combination may specify particular electrodes in a singlearray or multiple arrays, e.g., on a single lead or among multipleleads.

AIMD 14 may be responsive to adjustments of programming parameters andelectrode configurations by a user via programmer 20. In particular,processor 24 may receive adjustments to program parameters fromprogrammer 20 via telemetry circuit 28. Telemetry circuit 28 may supportwireless telemetry with external programmer 20 or another device byradio frequency (RF) communication, proximal inductive interaction ofAIMD 14 with external programmer 20, or other techniques. Telemetrycircuit 28 may send information to and receive information from externalprogrammer 20 on a continuous basis, at periodic intervals, or uponrequest from the stimulator or programmer. To support RF communication,telemetry circuit 28 may include appropriate electronic components, suchas amplifiers, filters, mixers, encoders, decoders, modulators,demodulators and the like. In some examples, processor 24 also maycommunicate information to programmer 20 or another external device viatelemetry circuit 28.

In some examples, memory 26 also may store parameters of differentoperating modes of AIMD 14. For example, one operating mode may be anMRI conditionally safe operating mode. In some examples, when in an MRIconditionally safe operating mode, processor 24 may suspend therapydelivery and enter a low power state. Processor 24 may switch from anormal operating mode, in which stimulation generator 30 deliverstherapy to patient 12 via electrodes carried by leads 16, to an MRIconditionally safe operating mode in response to an instruction receivedfrom an external device, such as, for example, programmer 20. In someexamples, in the MRI conditionally safe operating mode, processor 24 maycontrol the components of AIMD 14 to be in a low power mode thatprovides sufficient functionality to the components, e.g., processor 24and stimulation generator 30, to prevent stimulation therapy fromaccidentally being delivered to patient 12 during the MRI. In the MRIconditionally safe operating mode, according to some examples, AIMD 14may remain awake (operational) but does not actively deliver electricalstimulation to the patient.

Power source 32 delivers operating power to the components of stimulator14. Power source 32 may include a small rechargeable or non-rechargeablebattery and a power generation circuit to produce the operating power.Recharging may be accomplished through proximal inductive interactionbetween an external charger and an inductive charging coil within AIMD14. In some embodiments, power requirements may be small enough to allowAIMD 14 to utilize patient motion and implement a kineticenergy-scavenging device to trickle charge a rechargeable battery. Inother embodiments, traditional non-rechargeable batteries may be usedfor a limited period of time. As a further alternative, an externalinductive power supply could transcutaneously power AIMD 14 when neededor desired.

FIG. 3 is a functional block diagram illustrating various components ofan external programmer 20 for an AIMD 14. As shown in FIG. 3, externalprogrammer 20 includes processor 34, memory 36, telemetry circuit 40,user interface 38, and power source 42. In some examples, externalprogrammer 20 may be a patient programmer. A patient programmer may beportable and may be carried by patient 12 throughout his or her dailyroutine. A patient programmer may allow a patient to interact with userinterface 38 to select programs, adjust program parameters, and retrieveinformation from AIMD 14, e.g., on a limited basis as specified by theclinician. For example, the patient programmer may be configured topermit the patient amplitude, pulse width, or pulse rate adjustments tobe made only within a limited range, or to permit only particular setsof electrode configurations to be selected by the patient. In examplesin which external programmer 20 is a patient programmer, the patientprogrammer may allow the patient or another user, such as an MRItechnician or radiologist, to determine whether AIMD 14 is compatiblewith an MRI modality. Additionally, in some examples, the patientprogrammer may allow the patient or other user to instruct the AIMD 14to enter an MRI conditionally safe operating mode, which may configurethe AIMD 14 in a mode compatible with a scan by an MRI modality.

By utilizing a patient programmer to determine whether AIMD 14 iscompatible with an MRI modality, the patient may not need to visit aphysician who is managing therapy provided by AIMD 14 in order todetermine whether AIMD 14 is compatible with the MRI modality or tomodify the operating mode of AIMD 14 to the MRI conditionally safeoperating mode. In this way, the patient programmer may facilitate andexpedite determination of whether AIMD 14 is compatible with an MRImodality and preparation of AIMD 14 for the scan by the MRI modality. Insome examples, the patient programmer may implement at least onetechnique to enable patient 12 or another user to utilize the patientprogrammer to make the MRI compatibility determination without error orcomplication, as will be described below. For example, the patientprogrammer may automatically gather the information used to make the MRIcompatibility determination and make the determination automaticallywithout intervention by patient 12 or another user.

In other examples, external programmer 20 may be a clinician programmer.In the case of a clinician programmer, a clinician interacts with userinterface 38 in order to generate programs, adjust program parameters,such as voltage or current amplitude, pulse width, pulse rate, electrodecombinations and electrode polarities. A clinician programmer may permita clinician to control or adjust a larger, and perhaps complete, set oftherapy parameters, relative to the limited set of parameters adjustablevia a patient programmer. The clinician may also interact with userinterface 38 in order to retrieve information from AIMD 14, such asinformation pertinent to compatibility of AIMD 14 with an MRI modality,e.g., stored in memory 26 of AIMD 14. Generation of programs andadjustment of program parameters may be aided by automated programmingalgorithms that guide the physician or clinician to select particularprograms and program parameters.

User interface 38 may include a screen and one or more input buttonsthat allow external programmer 20 to receive input from a user. Thescreen may be a liquid crystal display (LCD), touch screen, or the like.The input buttons may include a touch pad, increase and decreasebuttons, emergency shut off button, and other buttons needed to controlthe stimulation therapy. In some cases, the user may interact with userinterface 38 via a stylus, soft keys, hard keys, directional devices,and any of a variety of other input media. Processor 34 receives inputfrom user interface 38, presents data via the user interface, retrievesdata from memory 36 and stores data within memory 36. Processor 34 alsocontrols the transmission of data via telemetry circuit 40 to AIMD 14.Memory 36 may include operational instructions for processor 34 orprogram parameter sets. For example, memory 36 may be a computerreadable storage medium comprising instructions that cause processor 34to perform various functions.

In some examples, memory 36 also may store information pertinent tocompatibility of AIMD 14 with an MRI modality. For example, memory 36may store a date on which AIMD 14 and/or leads 16 were implanted inpatient 12, a date on which any revision was made to AIMD 14 and/orleads 16, or a name and/or phone number of a physician who implantedAIMD 14 or manages care of patient 12. In some examples, memory 36 maystore a manufacturer of AIMD 14 and contact information for themanufacturer, an identifier of AIMD 14 and/or leads 16, such as a serialnumber, a model number, a registration number, or the like, or amagnetic field magnitude to which AIMD 14 safely can be exposed withoutharm to patient 12. Additionally or alternatively, memory 36 may storeinformation regarding an implant location of AIMD 14 and/or leads 16, apresence of another IMD implanted in patient 12, an indication of thepresence of an abandoned, broken, or damaged lead 16, or an impedance ofone or more of leads 16.

Telemetry circuit 40 allows the transfer of data to and from AIMD 14.Telemetry circuit 40 may communicate automatically with telemetrycircuit 28 of AIMD 14 at a scheduled time or when the telemetry circuitdetects the proximity of the stimulator. Alternatively, telemetrycircuit 40 may communicate with AIMD 14 when signaled by a user throughuser interface 38. To support RF communication, telemetry circuit 40 mayinclude appropriate electronic components, such as amplifiers, filters,mixers, encoders, decoders, modulators, demodulators and the like.

In some examples, telemetry circuit 40 may be used to obtain informationfrom memory 26 of AIMD 14 that is pertinent to compatibility of AIMD 14with an MRI modality. For example, in response to an input from a uservia user interface 28, such as an MRI compatibility input entered viauser interface 38, processor 34 may transmit an instruction viatelemetry circuit 40 to processor 24 of AIMD 14 to retrieve MRIcompatibility information from memory 26 and transmit the MRIcompatibility information via telemetry circuit 28 to externalprogrammer 20. Processor 34 then may utilize the MRI compatibilityinformation to determine whether AIMD 14 is compatible with an MRImodality. In some examples, processor 34 may display the results of thedetermination, e.g., that AIMD 14 is MRI compatible or MRI incompatible,to a user, such as patient 12, via user interface 38. Such a techniquemay be carried out by an external programmer 20 comprising either aclinician programmer or a patient programmer. A patient programmer thatis able to obtain MRI compatibility information and utilize theinformation to make an MRI compatibility determination or transmit theMRI compatibility information to another device may facilitatedetermination of MRI compatibility between AIMD 14 and an MRI modalitywithout visiting a clinician who is managing therapy provided by AIMD14. In this way, the patient programmer may facilitate and expeditedetermination of whether AIMD 14 is compatible with an MRI modality andpreparation of AIMD 14 for the scan by the MRI modality.

Based on the results of the determination, in some examples, the usermay then input a command via user interface 38 to cause the AIMD 14(e.g., processor 24 and stimulation generator 30) to enter an MRIconditionally safe operating mode. Processor 34 may transmit the commandto processor 24 of AIMD 14 via telemetry circuits 40, 28. In otherexamples, when processor 34 determines that AIMD 14 is compatible withthe MRI modality, processor 34 may automatically generate and transmitto processor 24 of AIMD 14 a command that causes AIMD 14 (e.g.,processor 24 and stimulation generator 30) to enter an MRI conditionallysafe operating mode. In additional examples, e.g., in which AIMD 14 isMRI safe or MRI conditionally safe without entering an MRI conditionallysafe operating mode, the patient may simply proceed with the MRIprocedure, based on the verification of MRI compatibility, with orwithout configuring AIMD 14 to enter an MRI conditionally safe operatingmode.

Power source 42 may be a rechargeable battery, such as a lithium ion ornickel metal hydride battery. Other rechargeable or conventionalbatteries may also be used. In some cases, external programmer 20 may beused when coupled to an alternating current (AC) outlet, i.e., AC linepower, either directly or via an AC/DC adapter.

FIG. 4 is a conceptual diagram illustrating an example computing system50 that includes a number of computing devices that may be connected toa network 66. In some examples, one or more of the devices of system 50may perform the techniques described in this disclosure, or mayfacilitate performance of the techniques described in this disclosure bya user, such as, for example, a medical technician, clinician, orpatient 12. In the example illustrated in FIG. 4, AIMD 14, patientprogrammer 62, clinician programmer 64, patient information terminal 52,MRI modality 54, patient data archive 56, MRI compatibility web server68 MRI data server 58, and AIMD data server 60 are connected via anetwork 66. While FIG. 4 shows system 50 as including nine devicesconnected via network 66, in other examples system 50 may include fewerthan eight devices or more than eight devices. For example, in somecases system 50 may include two or more of the devices depicted in FIG.4.

In the example of FIG. 4, system 64 includes a network 66. Network 66may be a wired or wireless network, or may comprise a combination ofwired and wireless networks. In some cases, network 66 may be formed bya local area network, a wide area network, or a global network such asthe Internet, or various combinations of such networks. As alternatives,one or more of the devices may exchange information with another deviceby other techniques, such as direct connect interfaces, infraredtelemetry, wireless telemetry, exchange of data storage media such asmemory cards or disks, or the like. The communication links betweenvarious devices illustrated in FIG. 4 may be accomplished through wiredcommunication protocols, wireless communication protocols, orcombinations thereof.

Patient information terminal 52 may include, for example, a laptopcomputer, a desktop computer, or a workstation located remote from theMRI facility executing a software program or accessing a website, intowhich the patient may enter and/or from which the patient may retrieveMRI compatibility information prior to arriving at the MRI facility. Thewebsite may be provided by MRI compatibility web server 68, which may beconfigured to serve web pages to guide MRI compatibility informationcollection, storage and retrieval to support the compatibilitydetermination. In other examples, the patient information terminal mayinclude a computer at the MRI facility that executes a software programor accesses a website into which the patient may enter and/or from whichthe patient may retrieve MRI compatibility information. In some cases,patient 12 may enter MRI compatibility information in patientinformation terminal 52, while in other cases a medical technician orclinician may collect MRI compatibility information from patient 12 andenter the information in the patient information terminal 52. In someexamples, a staff member of the MRI facility may enter and/or retrievesome information during registration of the patient at a computingdevice associated with the MRI facility, e.g., based on informationobtained from the patient over the telephone, or over other electroniccommunication media, such as email, web chat, video teleconference, orthe like. Hence, the patient information terminal 52 may be located atthe MRI facility or elsewhere, or presented by a web page or othercomputer interface at a location remote from the MRI facility.

In some examples, patient information terminal 52 may execute a softwareprogram or access a website, such as a website provided by MRIcompatibility web server 68, which provides instructions regarding theMRI compatibility information to be obtained from patient 12. Forexample, patient information terminal 52 may execute an applicationprogram that executes locally on patient information terminal 52 orremotely via network 66 and prompts a user, such as a medicaltechnician, clinician, or patient 12 to input pertinent MRIcompatibility information. Again, the program may be executed locally,or may be accessed via the network. The program may prompt the user toenter MRI compatibility information, and in some examples, may beprogrammed to evaluate the MRI compatibility information entered by theuser and present subsequent prompts to the user based on previouslyentered MRI compatibility information.

The user may input MRI compatibility information regarding the AIMD 14and patient 12 in patient information terminal 52. For example, the usermay input a date on which AIMD 14 and/or leads 16 were implanted inpatient 12 or a date on which a revision was made to AIMD 14 and/orleads 16. The revision may include, for example, a subsequent surgicalprocedure to repair or modify AIMD 14 or a surgical procedure toreplace, modify, or implant leads 16 that connect to AIMD 14. The useralso may input a name and/or phone number of a physician who implantedAIMD 14 in patient 12. In some cases, the user may further input thename and/or phone number of a physician who manages the care of patient12, including therapy delivered by AIMD 14. The user also may input thename of the manufacturer of AIMD 14, a website address of themanufacturer, or an identifier of AIMD 14 and/or leas 16, such as amodel number, a serial number, a registration number, or the like. Insome examples, the user may additionally or alternatively input thatpatient 12 has another IMD implanted in his or her body and, optionally,MRI compatibility information regarding the other IMD.

In some examples, the user also may input information regarding alocation at which AIMD 14 is implanted in patient 12, such as, forexample, torso, right or left leg, cranium, or more specific locationinformation. The user may collect the implant location information frompatient 12, may retrieve the implant location from memory 36 ofprogrammer 20, or may retrieve the implant location from memory 26 AIMD14 via programmer 20. In other examples, the user may determine theimplant location using a metal detector or an x-ray imaging device whichdetects a radio-opaque marker in AIMD 14 and/or leads 16. In examples inwhich the AIMD 14 is compatible with an MRI modality, the user mayfurther input a magnetic field strength with which AIMD 14 iscompatible, e.g., based on retrieval of information indicating thethreshold.

In some examples, at least some of the MRI compatibility informationdiscussed above may be stored on a patient ID card or AIMD CompatibilityDocumentation. Patient 12 may carry the patient ID card as a referencefor the information contained thereon, and may present the patient IDcard to a user, who then enters the information from the patient ID cardin patient information terminal 52. In other examples, patient 12 mayenter the MRI compatibility information from the patient ID card inpatient information terminal 52. The patient ID card may assist the userin obtaining pertinent MRI compatibility information in cases in whichpatient 12 is not able to communicate the pertinent information, e.g.,because of language barriers, a medical condition such as loss ofconsciousness, or the like.

AIMD Compatibility Documentation may also contain at least some of theinformation discussed above. The AIMD Compatibility Documentation mayhave been produced recently by a health care provider, such as animplanting, managing, or referring physician, based on the health careprovider's knowledge of the MRI compatibility of AIMD 14. AIMDCompatibility Documentation may be possessed by patient 12 andcommunicated or provided to a user who enters the pertinent data intopatient information terminal 52 or another computing device. The MRICompatibility Documentation may assist the user in obtaining pertinentMRI compatibility information in cases in which patient 12 is not ableto communicate the pertinent information, e.g., because of languagebarriers, a medical condition such as loss of consciousness, or thelike.

In some examples, at least some of the MRI compatibility informationdiscussed above may be stored in memory 26 of AIMD 14. Informationstored in memory 26 may be retrieved by via external programmer 20 oranother device, e.g., via wireless telemetry, and may be communicated toanother device via network 66. Memory 26 may store, for example, one ormore of an implant date or a revision date, a physician name and/ortelephone number, a manufacturer name, a serial number, a model number,a registration number, an implant location, a magnetic field strength, apresence of another IMD implanted in patient 12, or the like. In someexamples, some MRI compatibility information may be stored in memory 26of AIMD 14 while some MRI compatibility information is stored in memory36 of external programmer 20. In some examples, at least some of the MRIcompatibility information may be stored in memory 26 and memory 36.External programmer 20 then may communicate the MRI compatibilityinformation to another device, such as, for example, MRI modality 54 orpatient information terminal 52, via network 66.

In some examples, at least some of the MRI compatibility informationdiscussed above may be stored in memory 36 of patient programmer 62.Patient programmer 62 may include components similar to thoseillustrated in FIG. 3 for external programmer 20 (e.g., processor 34,memory 36, user interface 38, telemetry circuit 40, and power source42). In some examples, patient programmer 62 may connect to network 66and may communicate the MRI compatibility information in response to aquery from another device, such as, for example, MRI modality 54,patient information terminal 52, or the like. In other examples, a user,such as patient 12, may retrieve MRI compatibility information frommemory 36 of patient programmer 62 via user interface 38. The MRIcompatibility information stored on patient programmer 62 may include,for example, one or more of an implant date or a revision date, aphysician name and/or telephone number, a manufacturer name, a serialnumber, a model number, a registration number, an implant location, amagnetic field strength with which AIMD 14 is compatible, a presence ofanother IMD implanted in patient 12, or the like.

Patient programmer 62 may allows a patient to interact with userinterface 38 to select therapy programs, adjust therapy programparameters, and retrieve information from AIMD 14, e.g., on a limitedbasis as specified by the physician or clinician. Patient programmer 62may be portable or highly portable and allow patient 12 to carry orutilize patient programmer 62 throughout their day. Patient programmer62 may allow the patient or another user, such as an MRI technician orradiologist, to determine whether AIMD 14 is compatible with MRImodality 54. Additionally, in some examples, patient programmer 62 mayallow the patient or other user to instruct the AIMD 14 to enter an MRIconditionally safe operating mode, which may configure the AIMD 14 in amode compatible with a scan by MRI modality 54.

In some examples, a user, such as a clinician or MRI technician, mayutilize clinician programmer 64 to retrieve MRI compatibilityinformation stored in memory 36 of patient programmer 62 or memory 26 ofAIMD 14. A clinician programmer may permit a clinician to control oradjust a larger set of therapy parameters of AIMD 14 than a patientprogrammer, and may be utilized by the clinician who implanted AIMD 14or manages therapy delivered to patient 12 by AIMD 14. Clinicianprogrammer 64 may include components similar to those illustrated inFIG. 3 for external programmer 20 (e.g., processor 34, memory 36, userinterface 38, telemetry circuit 40, and power source 42). The MRIcompatibility information retrieved using clinician programmer 64 mayinclude, for example, one or more of an implant date or a revision date,a physician name and/or telephone number, a manufacturer name, a serialnumber, a model number, a registration number, an implant location, amagnetic field strength with which AIMD 14 is compatible, a presence ofanother IMD implanted in patient 12, or the like.

Some of the MRI compatibility information may be stored in AIMD dataserver 60, which may be maintained by the manufacturer of AIMD 14, thehospital or clinic at which AIMD 14 was implanted in patient 12, or athird party. AIMD data server 60 may store any of the MRI compatibilityinformation regarding AIMD 14, including, for example, implant date orrevision date, physician name and/or telephone number, manufacturername, serial number, a model number, a registration number, implantlocation, compatible magnetic field strength, or the like. In othercases, AIMD data server 60 may not store MRI compatibility informationspecific to the patient 12, but may store MRI compatibility informationrelating to design specifications or MRI compatibility of particularAIMD models. In some examples, at least some of the MRI compatibilityinformation may be stored by at least two of AIMD data server 60, memory26 of AIMD 14, and memory 36 of patient programmer 62 or clinicianprogrammer 64. AIMD data server 60 may communicate the MRI compatibilityinformation via network 66 to another device connected to network 66.

Similarly, MRI data server 58 may store MRI compatibility informationrelated to operation of MRI modality 54. MRI data server 58 may beoperated by, for example, the manufacturer of MRI modality 54, thehospital or clinic which operates imaging modality 54, or a third party.MRI data server 58 may store, for example, operational parameters of theparticular MRI modality 54, or different types of MRI modalities, suchas magnetic field magnitude, a RF coil type, e.g., single ormultichannel, or the like. MRI data server 58 may communicate theinformation for the particular MRI modality 54 to be used for theimaging procedure to another device connected to network 66 upon receiptof a prompt to do so.

System 50 also includes a patient data archive 56. Patient data archive56 may store information regarding the outcome of the techniquesdescribed in this disclosure. That is, patient data archive 56 may storeanswers to the questions investigated during practice of the describedtechniques. For example, patient data archive 56 may store eachindividual question and the answer to each question for each instancethe technique is performed. Patient data archive 56 may associate thequestions and answers with the particular patient 12 who was seekingclearance for an MRI scan. As another example, patient data archive 56may store the outcome of the technique, e.g., MRI allowed or MRI notallowed, but may not store the answers to the individual questions ofthe technique. In some cases, the records maintained by patient dataarchive 56 may include a scope and form of information suitable forcompliance with applicable regulatory requirements.

MRI modality 54 may include an MRI scanner 55 and an MRI console 57 thatpresents a user interface to a user that facilitates control of the MRIscanner 55. In some examples, the console 57 may allow a user, such asan MRI technician or a clinician to configure MRI scanner 55 to operatein a manner with which AIMD 14 is compatible. For example, the user mayconfigure the MRI scanner 55 to produce a magnetic field having amagnitude compatible with AIMD 14. MRI scanner 55 may comprise aconventional MRI scanner, and may include, for example, a single channelor multiple channel RF coil.

FIG. 5 is a flow diagram illustrating one example technique according towhich MRI compatibility of an AIMD 14 implanted in patient 12 may bedetermined. The example depicted in FIG. 5 includes six steps. However,in other examples, a technique for determining MRI compatibility of anAIMD 14 may not include all six steps. In general, a technique fordetermining MRI compatibility of AIMD 14 may include one or more of thesteps depicted in FIG. 5.

For example, a technique for determining compatibility of AIMD 14 withan MRI modality, e.g., modality 54, may include three steps. The firststep may include obtaining information regarding compatibility of AIMD14 with an MRI scan. The second step may include obtaining MRI modalityinformation regarding operation of an MRI modality. The third step mayinclude determining whether AIMD 14 is compatible with the MRI modalitybased on the AIMD information and the MRI modality information.

The technique illustrated in FIG. 5 will be described as being performedby one or more of the computing devices of computing system 50 (FIG. 4)executing a software program or web pages. However, in other examples,the technique shown in FIG. 5 may be implemented at least in part usingwritten materials such as a poster or instruction sheet and performed bya user. The poster or instruction sheet may guide a user, such as an MRIfacility staff person, an MRI technician, a clinician, patient 12, or acombination of two or more of these users, in collecting and evaluatinginformation regarding compatibility of AIMD 14 and MRI modality 54.

In the example shown in FIG. 5, one or more computing devices of system50 first obtains AIMD information via one or more devices of system 50(72). If an attempt to obtain AIMD information (72) is unsuccessful, asdescribed below, further investigation (90) may be necessary, e.g., byan MRI technician or other person, to ensure MRI compatibility of theAIMD 14 implanted in the patient 12. As described above, one of a numberof devices in system 50 may obtain the AIMD information. For example,system 50 may obtain AIMD information via entry by a user throughpatient information terminal 52 or MRI modality 54, or may obtain AIMDinformation from AIMD data server 60. In some examples, patient 12 mayknow and remember at least some of the AIMD information or may possess apatient ID card with the AIMD information printed thereon. Patient 12may input the information when prompted by patient information terminal52, which may be located at the MRI facility, in a clinic, or accessedremotely, or may provide the information to an MRI technician,clinician, or MRI facility staff person, e.g., orally or in writing, toenter the AIMD data into the appropriate device of system 50. In otherexamples, patient 12 may possess AIMD Compatibility Documentationproduced by a health care provider such as an implanting, managing, orreferring physician, which may provide at least some of the AIMDinformation. Patient 12 may input the information from AIMDCompatibility Documentation when prompted by patient informationterminal 52, or may provide the information to an MRI technician,clinician, or MRI facility staff person to enter the AIMD data into theappropriate device of system 50. In still other examples, patient 12 maycarry a patient programmer 62, and a memory 36 of patient programmer 62may store at least some of the AIMD information. In some examples,instead of memory 36 of patient programmer 62 storing the AIMDinformation, a memory 26 of AIMD 14 may store at least some of the AIMDinformation and a user may utilize patient programmer 62 or a clinicianprogrammer 64 to access the AIMD information. Patient programmer 62 orclinician programmer 64 may communicate the AIMD information to apatient information terminal 52 or network 66 upon prompting by terminal52 or network 66.

As described above, the AIMD information may include, for example, animplant date of AIMD 14 and/or leads 16 in patient 12, a date at which arevision to AIMD 14 and/or leads 16 occurred, a presence of another IMDimplanted in patient 12, a serial number, a model number, or aregistration number of AIMD 14 and/or leads 16, the name or phone numberof the physician who implanted the AIMD 14, the name or phone number ofthe physician managing care of patient 12, or a website or phone numberof the manufacturer of AIMD 14. The AIMD information is used by acomputing device of system 50 to determine features of AIMD 14 andwhether AIMD 14 is compatible with an MRI modality 54 or an MRI scanner55.

As described above with respect to FIG. 4, in some examples, patientinformation terminal 52 may comprise a web application or other computerprogram that patient 12 may access prior to or upon arriving at the MRIfacility. In some cases, patient 12 may enter the AIMD informationthrough patient information terminal 52 at his or her convenience priorto an MRI appointment. For example, patient 12 may access a website froma personal computer located at his or her home or another location. Theweb site may prompt patient 12 to enter AIMD information, and may guidepatient 12 through entry of the AIMD information. For example, thewebsite may include illustrations or other aids that assist patient 12in retrieving the AIMD information from his or her patient ID card, apatient programmer, or AIMD 14 via the patient programmer. In somecases, a website may be presented by MRI compatibility web server 68 orby some other web server.

In other examples, a staff person at the MRI facility may contactpatient 12 via a telephone call to collect the AIMD information prior tothe arrival of patient 12 at the MRI facility. The staff person maycontact patient 12 and enter the AIMD information into patientinformation terminal 52 or MRI modality 54 prior to scheduling the MRIprocedure for patient 12, or may collect the AIMD information shortlybefore an appointment of patient 12, e.g., one to three days prior tothe appointment.

In other examples, an MRI facility staff person may collect the AIMDinformation and input the AIMD information into patient informationterminal 52 or MRI modality 54 when patient 12 registers for theirappointment upon arrival at the MRI facility. In still other examples,an MRI technician or a clinician may collect the AIMD information andenter the AIMD information into patient information terminal 52 or MRImodality 54 during the appointment and prior to the MRI scan.

In some examples, the AIMD information may be stored in AIMD data server60 (FIG. 4). AIMD data server 60 may be accessed by a user, such aspatient 12, the staff person, the MRI technician, or the clinician toretrieve the AIMD information. In some cases, a processor, e.g., aprocessor of patient information terminal 52 or MRI modality 54, whichis executing the software program or website, may access the informationstored by AIMD data server 60 in response to instructions from thesoftware program or website. Alternatively, MRI compatibility web server68 may access AIMD data server 60 or MRI data server 58 automatically toobtain information for presentation or processing by MRI compatibilityweb server 68, patient information terminal 52, MRI modality 54, orother components. The instructions may be generated in response to otherdata input by the user, such as the name of patient 12, the manufacturerof the AIMD, the clinic or hospital at which AIMD 14 was implanted inpatient 12, or the like.

In any of the above examples, upon collection, the AIMD information maybe stored in a database that is accessible by any authorized deviceconnected to a network, e.g., network 66. This may facilitate entry ofdifferent portions of the pertinent information at different devices orlocations, e.g., MRI modality 54, patient information terminal 53, AIMDdata server 60, or by different users, e.g., patient 12, a staff personat the MRI facility, an MRI technician, or a clinician. In someexamples, the AIMD information stored in the database may be accessiblesubsequent to the appointment for which the information is beingcollected. For example, the AIMD information stored in the database maybe accessible for use during evaluation of future MRI scans. In otherexamples, the AIMD information may be entered on a medical chart thatfacilitates organization of information and performance of thetechniques described in this disclosure.

In examples in which the pertinent AIMD information can be obtained byone or more computing devices of system 50, e.g., patient informationterminal 52, patient programmer 62, MRI modality 54, clinicianprogrammer 64, AIMD data server 60, MRI data server 58, or MRIcompatibility web server 68, the technique proceeds to determiningcompatibility between AIMD 14 and MRI scanner 55 (74). However, when theAIMD information cannot be obtained, such as when patient 12 hasforgotten his or her patient ID card or cannot communicate theinformation due to language barriers or medical conditions, e.g.,unconsciousness, further investigation is necessary prior to authorizingor refusing the MRI scan (90).

Once the AIMD information has been collected (72), one or more device insystem 50 determines compatibility of AIMD 14 and the MRI scanner 55 atthe MRI facility (74). In some examples, AIMD 14 may be compatible withcertain types of MRI scanners, but may not be compatible with othertypes of MRI scanners. To determine compatibility between AIMD 14 andthe particular MRI scanner 55, system 50 acquires information regardingthe MRI modality 54, such as the type of MRI scanner 55, the RF coiltype, and the like. For example, MRI compatibility web server 68 mayinteract with MRI data server 58 or MRI modality 54 to obtain suchinformation.

In some examples, the type of MRI scanner 55 may include the modelnumber and manufacturer of the MRI scanner 55. In other examples, thetype of MRI scanner 55 may include the magnet type and the magneticfield strength produced by the MRI scanner 55. For example, an AIMD 14may be compatible with an MRI scanner 55 that produces a magnetic fieldhaving a magnitude of 1.5 T. In other examples, the magnetic field withwhich AIMD 14 is compatible may be different (e.g., greater than 1.5 Tor less than 1.5 T). The RF coil type may include an indication whetherthe RF coil is a single channel or a multiple channel RF coil.

A computing device of system 50 or a user interacting with system 50 mayretrieve the MRI modality information from, for example, the MRImodality 54 itself, such as software used to operate the MRI modality 54or physical labeling of the modality 54. In other examples, the MRImodality information may be stored on MRI data server 58 (FIG. 4) andmay be accessed by a user, such as a staff person at the MRI facility,an MRI technician, or a clinician, or by a device such as MRIcompatibility web server 68. In other examples, a device, e.g., patientinformation terminal 52 or MRI modality 54, that is executing anapplication software program or website may access the informationstored by MRI data server 58 in response to an instruction from thesoftware program or website.

The instructions may be generated in response to other information inputby the user, such as the model number or serial number of MRI modality54, the manufacturer of the MRI modality 54, the name of the MRIfacility, or the like. As described above, MRI data server 58 may bemaintained by the MRI facility, a manufacturer of the MRI modality 54, amanufacturer of AIMD 14, or a third party. In some examples, the user,MRI compatibility web server 68, patient information terminal 52, or MRImodality 54 may access MRI data server 58 indirectly by, for example,calling the maintainer of the database or accessing the database througha website or other computing interfaces. Notably, the variousinformation collection and determination tasks may be performed by onecomputing device or distributed among various computing devices insystem 50.

One or more of the computing devices of system 50 may compare the MRImodality information and the AIMD information to determine whether AIMD14 is compatible with the MRI scanner 55 at the MRI facility (74). Insome examples, patient information terminal 52, MRI compatibility webserver 68, patient programmer 62, clinician programmer 64, or MRImodality 54 may determine whether AIMD 14 and the MRI scanner 55 arecompatible based on the MRI modality information and the AIMDinformation. Any of such computing devices may be programmed orotherwise configured to automatically compare AIMD information and MRImodality information to determine compatibility of the particular AIMDwith the particular MRI modality. In other examples, a user, such as anMRI technician, clinician, or MRI facility staff member, may make thecompatibility determination based on the MRI modality information andthe AIMD information. In some examples, the user may be assisted inmaking the determination by a software program or website executed byone of the devices in system 50.

For example, the computing device (e.g., patient information terminal52, MRI compatibility web server 68, patient programmer 62, clinicianprogrammer 64, or MRI modality 54) or a user may compare a magneticfield with which AIMD 14 is compatible to a magnetic field, e.g., amagnetic field produced by a particular set of MRI scan parameters,produced by the MRI scanner 55. If the computing device or userdetermines that AIMD 14 is not compatible with the MRI scanner 55 at theMRI facility, the computing device or user of system 50 outputs anindication that AIMD is incompatible with the MRI scanner 55 and the MRIscan is refused (88). In some examples, the computing device or user maynot determine that AIMD 14 is incompatible with the MRI scanner 55,because one or both of the AIMD information and the MRI modalityinformation may be incomplete, unclear, or conflicting. In these cases,the computing device may alert the user of the questionable information,and may refuse to authorize MRI scan until the information is correctedor provided. In other examples, when the user determines that AIMD 14 isnot compatible with the MRI scanner 55 at the MRI facility, the useralerts patient 12 that an MRI scan will not be performed on patient 12.

However, when a computing device of system 50 or the user determinesthat AIMD 14 is compatible with the MRI scanner 55, the computing deviceor user proceeds to confirm that hardware of AIMD 14 is MRICS or MRIS(76). The computing device or user of system 50 may confirm that theAIMD 14 comprises MRICS or MRIS hardware by collecting informationincluding, for example, the implant date of AIMD 14 and/or leads 16, themodel number, serial number or registration number of AIMD 14 and/orleads 16, or other information. In some examples, the implant date maybe utilized as a sort of threshold qualification in determining whetherthe implant comprises MRICS hardware. For example, it may be known thatan AIMD 14 or leads 16 implanted prior to a certain date would not haveincluded MRICS or MRIS hardware.

The information used to confirm that AIMD 14 comprises MRICS or MRIShardware may further include a serial number, model number, orregistration number of AIMD 14 and/or leads 16 coupled to AIMD 14. Insome examples, the serial number, registration number, or model numbermay be provided on the patient ID card, or may be stored in memory 36 ofpatient programmer 62 or clinician programmer 64. In other examples, theserial number, registration number, or model number may be stored inmemory 26 of 1 MB 16 and may be retrieved using patient programmer 62 orclinician programmer 64. The serial number, registration number or modelnumber of AIMD 14 and leads 16 may be used by a computing device ofsystem 50 or the user to retrieve information regarding AIMD 14 or leads16 from an AMD data server 60, a manufacturer's website, a third partywebsite, or via a phone call to the AIMD manufacturer or a third party.In some examples, the computing device that is executing the softwareprogram or website may utilize the serial number, registration number,or model number to retrieve data regarding the AIMD from AIMD dataserver 60. In some examples, the computing device may execute analgorithm that identifies certain values or patterns of a model number,registration number, or a serial number as corresponding to an AIMD thatdoes or does not comprise MRICS or MRIS hardware. For example, thecomputing device may utilize the first four characters of a modelnumber, registration number, or serial number of AIMD 14 or leads 16 andcompare these four characters to a database including entries comprisingthe first four characters of a plurality of AIMDs or leads. Thecomputing device may then make a determination of MRI compatibility ofthe AIMD 14 based on the results of the comparison of the characters ofthe serial number, registration number, or model number with entries inthe database.

The information used by a computing device of system 50 to confirm thatAIMD 14 comprises MRICS or MRIS hardware also may include a softwarelockout check. In some examples, memory 26 or AIMD 14 may store a serialnumber of AIMD 14, a serial number of leads 16 coupled to AIMD 14, andan implant location of AIMD 14 and leads 16. Based on the serial numbersand the implant location, AIMD 14 may determine whether the system,e.g., AIMD 14 and leads 16 is MRICS or MRIS. The software lockout check,then, may comprise interrogating AIMD 14 with patient programmer 62 orclinician programmer 64 to retrieve an indication of whether the systemis MRICS or MRIS.

In other examples, upon implant of AIMD 14 and leads 16, an implantingphysician or another user may communicate the serial number of AIMD 14,serial number of leads 16, and the implant location to a manufacturer ofAIMD 14 or a third party, such as a third party that maintains MRIcompatibility information for various AIMDs. The manufacturer or thirdparty may determine whether the system is MRICS or MRIS based on theserial numbers and the implant location. In some examples, themanufacturer or third party may issue a MRICS card that indicates thatAIMD 14 and leads 16 do or do not form an MRICS or MRIS system topatient 12, may issue a patient ID card with an indication that AIMD 14and leads 16 do or do not form an MRICS or MRIS system, or may store theMRICS information for the system in a database on a server, e.g., AIMDdata server 60 or patient data archive 56. The software lockout check,then, may include obtaining this information from the MRICS card, thepatient ID card, or the database. In some examples, a manufacturer ofAIMD 14 may provide a blank MRICS card to the implanting physician, whomay fill out the MRICS with, for example, a serial number of AIMD 14and/or leads 16, and implant location of AIMD 14 and/or leads 16, or anindication of whether the system formed by AIMD 14 and leads 16 is MRICSor MRIS. In some examples, the information used by a computing device ofsystem 50 to confirm that AIMD 14 comprises MRICS or MRIS hardware mayinclude implant information such as lead location or the presence ofabandoned leads. In some examples, the implant information may be storedin memory 26 of IMD 16 and may be retrieved by a user via patientprogrammer 62 or clinician programmer 64. In other examples, the implantinformation may be stored in memory 36 of patient programmer 62 orclinician programmer 64.

In some examples, the implant information may be obtained by a user,such as a clinician, MRI technician or MRI facility staff person using ametal detector scan of patient 12 or an x-ray or fluoroscopy image ofpatient 12. For example, the metal detector scan of patient 12 mayindicate approximate locations of metal objects in patient 12, which mayinclude leads 16 and AIMD 14. In some examples, AIMD 14 or leads 16 mayinclude a radio-opaque marker that may be seen on an x-ray image or afluoroscopic image. The x-ray image or fluoroscopic image may facilitatemore precise location of leads 16 or AIMD 14. When a computing device ofsystem 50 determines that AIMD 14 does not comprise MRICS hardware (76),system 50 generates a notification that AIMD 14 is not compatible withthe MRI scanner 55 and patient 12 will not undergo an MRI scan (88).

When a computing device of system 50 determines that AIMD 14 does, infact, comprise MRICS or MRIS hardware, the computing device proceeds toprompt a user to determine and input the AIMD location and any MRICShardware exceptions (78), e.g., via patient information terminal 52,patient programmer 62, or clinician programmer 64. In some examples, theuser may determine the AIMD location or MRICS hardware exceptions byx-ray images or fluoroscopic images. For example, the x-ray orfluoroscopic images may show an abandoned lead, i.e., a lead that is notcoupled to an IMD, or a lead that is broken or damaged. In otherexamples, the user may determine the AIMD location or MRICS hardwareexceptions by retrieving information stored in memory 26 of AIMD 14 ormemory 36 of patient programmer 62 or clinician programmer 64. In stillother examples, system 50 or the user may retrieve the information fromAIMD data server 60, by a phone call to the manufacturer of AIMD 14, orby accessing a website of the manufacturer. In some examples, retrievingthe information from the manufacturer may require the serial number ofAIMD 14, and may only work when AIMD 14 has been registered with themanufacturer.

Some locations at which AIMD 14 or leads 16 are implanted may precludepatient 12 from having an MRI scan. For example, leads 16 may beimplanted proximate to a particular anatomical target of the patient 12,or near a target that does not correspond to a customary implantlocation. Similarly, leads 16 that are orphaned, i.e., unconnected to astimulator, or damaged may preclude patient 12 from having an MRI scandue to potential overheating of the leads 16. When a computing device ofsystem 50 determines that AIMD 14 is implanted in a location thatprecludes an MRI scan or patient 12 has implanted leads 16 that aredamaged or orphaned (78), the computing device may generate anotification to a user that patient 12 cannot undergo an MRI scan (88).

When a computing device of system 50 determines that the AIMD 14 isimplanted in a location that does not preclude an MRI scan and patient12 does not have any implanted leads that are damaged or orphaned, thecomputing device proceeds to prompt the user to prepare AIMD 14 for anMRI scan (80). In some examples, the user may prepare AIMD 14 for theMRI scan by controlling AIMD 14 to perform a lead impedance test foreach lead 16A, 16B that is coupled to AIMD 14. The impedance test may bean open/close test that indicates whether any of leads 16 includes abroken conductor, which may produce an open circuit. The impedance testalso may indicate presence of contact between two conductors, whichresults in a short circuit. In some examples, when the impedance testindicates an open circuit or a short circuit, the user may input thisinto a computing device in system 50 (e.g., patient information terminal52, MRI modality 54, patient programmer 62, or clinician programmer 64).A computing device of system 50 may then generate a notification to theuser that patient 12 cannot undergo an MRI scan (88). In other examples,when the impedance test indicates an open circuit or a short circuit theuser may recognize that this prevents patient 12 from undergoing an MRIscan, and the user may notify patient 12 of this fact (88).

However, when the impedance test indicates that the leads 16 arefunctional and AIMD 14 is functioning correctly, the user may proceed toensure that AIMD 14 is in an MRI conditionally safe operating mode. Insome examples, AIMD 14 may permanently be in an MRI conditionally safeoperating mode (e.g., AIMD 14 is MRIS, or a normal operating mode ofAIMD 14 is MRICS), and the user may not adjust AIMD 14 in any way. Inother examples, the user may configure AIMD 14 to be in an MRIconditionally safe operating mode using external programmer 20. The MRIconditionally safe mode may include features that prevent AIMD 14 frominadvertently delivering stimulation to patient 12 during the MRI scan.For example, the MRI conditionally safe operating mode may place AIMD 14in a low power state in which AIMD 14 does not deliver stimulation, butwhich prevents accidental provision of stimulation to patient 12. Insome examples, AIMD 14 may include two or more MRI conditionally safeoperating modes, which include different operating parameters, or whichmay result in AIMD 14 being compatible with different MRI scanparameters or different MRI modalities. In some examples, AIMD 14 may beproviding life-sustaining therapy, and may not be able to be placed inan MRI conditionally safe operating mode in which stimulation isinterrupted. In these examples, patient programmer 62 or clinicianprogrammer 64 may indicate this fact to the user, and the user mayinform patient 12 that he or she cannot undergo an MRI scan (88).

When AIMD 14 has been prepared for the MRI scan (80), a computing deviceof system 50 prompts the user to prepare the MRI scanner 55 for scanning(82). Preparation of the MRI scanner 55 for scanning includes, forexample, scan parameter validation, e.g., setting or confirming MRI scanparameters according to which the MRI scanner 55 will scan patient 12.The MRI scan parameters may include, for example, a magnetic fieldmagnitude and a gradient strength. A magnetic field that is too high maynot be suitable for a patient 12 having an AIMD 14 implanted in his orher body, as described above. Similarly, a gradient strength that is toolarge may not be suitable for a patient having an AIMD 14 implanted inhis or her body.

A user, such as a clinician or MRI technician, may be responsible forsetting and confirming the MRI scan parameters. The user should confirmthat the MRI scan parameters adhere to the guidelines of the AIMD 14implanted in patient 12. In some examples, the user may consult aradiologist or a manufacturer of AIMD 14 for assistance in setting theMRI scan parameters. For example, the user may contact the manufacturerof AIMD 14 via a phone call or a website of the manufacturer.

The user may also confirm that the RF coil of the MRI scanner 55 iscompatible with AIMD 14. For example, AIMD 14 may be compatible onlywith an MRI scanner 55 that include a single channel RF coil, and maynot be compatible with an MRI scanner 55 that includes a multiplechannel RF coil. As another example, a quadrature bird cage RF coil mayfunction in linear mode and cause AIMD 14 to be exposed to an excessivemagnetic field.

In some examples, the user may perform a test MRI scan, e.g., an MRIscan that is not performed on patient 12, to ensure proper functioningof the MRI RF coil. If the test scan fails to produce expected imagequality or indicates improper operation of the MRI RF coil, the MRIscanner 55 may not be suitable to scan patient 12, and furtherinvestigation may be required (90).

In some examples, the MRI scanner 55 may include an AIMD mode thatassures stringent internal limits on operation of the MRI scanner 55 toprevent AIMD 14 from being exposed to excessive magnetic fields. Theuser may configure the MRI scanner 55 in the AIMD mode prior to scanningpatient 12. Once the MRI scanner 55 is prepared for scanning (82), theuser may initiate the MRI scan of patient 12 (84).

Finally, regardless of whether the previous steps of the techniqueresulted in an MRI scan of patient 12 or a notification that patient 12cannot undergo an MRI scan, the MRI compatibility information collectedin the preceding steps and/or the results of the determinations made bya computing device of system 50 or a user may optionally be archived inpatient data archive 56 (86). The archiving of the MRI compatibilityinformation collected by the technique may provide defense againstmalpractice claims in the event patient 12 undergoes an MRI scan and isinjured, or may provide evidence of regulatory compliance. As describedabove, patient data archive 56 may comprise database of MRIcompatibility information regarding a plurality of patients, which maybe maintained by the MRI facility, an organization with which the MRIfacility is associated, or a third party. In some examples, patient dataarchive 56 may include an electronic and/or printed copy of theinformation collected and the determinations made by a computing deviceof system 50 or a user.

In some examples, some or all of the information collected in thevarious steps of the technique illustrated in FIG. 5 may be stored in aDigital Imaging and Communications in Medicine (DICOM) Modality Worklistrecord, which may be subsequently available to MRI technicians or otherclinician. For example, AIMD information obtained in step (72) and MRImodality information obtained in step (74) may be stored in the DICOMModality Worklist record. In some examples, this may enable the MRIscanner 55 to automatically configure itself in an AIMD mode uponidentification of patient 12. Further, in some examples, the AIMDinformation may be saved into the DICOM images for future reference.

As described briefly above, although the above example may be directedto a technique implemented in software or a website by one or morecomputing devices in system 50, in other examples, the technique may beembodied in operations carried out by a user with the aid of writtenmaterials such as a poster or instruction sheet that guides a user toperform the steps of the technique described with reference to FIG. 5.The written materials may be presented in hard copy form or in soft copyform via a computer. The written materials may include graphical and/ortextual information or instructions that facilitate determination ofwhether AIMD 14 and the MRI modality 54 satisfy the variousdeterminations required to indicate compatibility between AIMD 14 andthe MRI modality 54. Hence, the written materials may be presented to auser by a computing device as an interactive guide document forcollecting information to determine compatibility of an AIMD and an MRIscanner. The computing device may then collect the information in theguide document upon entry by the user for use in the compatibilitydetermination. In addition, such written materials may include areas toenter information, either electronically via a computer or manually viaa writing instrument, to record collected information relating to thecompatibility determination, as well as the compatibility determinationitself.

While the example illustrated in FIG. 5 is directed to one or more ofthe devices in system 50 obtaining the MRI compatibility information anddetermining or guiding a user in determining whether AIMD 14 is MRIcompatible, in some examples, a technique which is automated may beimplemented by a processor in a device of system 50. FIG. 6 is a flowdiagram illustrating another example of a technique that may beperformed to determine whether an AIMD 14 is compatible with an MRImodality 54. FIG. 6 will be described with concurrent reference to FIG.4 for convenience, although the technique illustrated in FIG. 6 may beperformed by another system, by a system comprised of a subset of thedevices illustrated in FIG. 4, or the like.

The technique illustrated in FIG. 6 may be implemented by a processor.The processor may be included in one of the devices shown in FIG. 4. Forexample, one or more of patient information terminal 52, MRI modality54, patient programmer 62, clinician programmer 64 or MRI compatibilityweb server 68 may form a computer hardware device that includes theprocessor. While described as being implemented by a processor, thetechnique shown in FIG. 6 may be implemented in hardware, software,firmware or any combination thereof. Additionally, the term processor isused to refer to one or more microprocessors, digital signal processors(DSPs), application specific integrated circuits (ASICs), fieldprogrammable gate arrays (FPGAs), or any other equivalent integrated ordiscrete logic circuitry, as well as any combinations of suchcomponents.

Initially, the processor may automatically obtain MRI compatibilityinformation from at least two sources (92). As used herein, the phrase“automatically obtain MRI compatibility information” is used to denote atechnique implemented by the processor which does not require userintervention once the technique has begun. In some examples, theautomatic information retrieval may be initiated by a command from auser, such as patient 12, a MRI technician, a clinician, or the like.Once the technique is initiated, the processor may retrieve the MRIcompatibility information from at least two sources without furtherintervention by the user.

The processor may automatically obtain MRI compatibility informationfrom, for example, two or more of AIMD 14, patient programmer 62,clinician programmer 64, AIMD data server 60, MRI data server 58,patient data archive 56, and/or MRI modality 54. In some examples, theprocessor may be included in one of the devices (e.g., processor 34 ofexternal programmer 20) and the processor may obtain at least some ofthe MRI compatibility information from a memory or database of thedevice in which the processor is located. Additionally or alternatively,the processor may utilize network 66 or another communication means toobtain the MRI compatibility information from at least one device inwhich the processor is not located. In some examples, the processor mayobtain MRI compatibility information from at least two sources that areexternal to the device in which the processor is located.

As described above, the MRI compatibility information may includeinformation regarding AIMD 14, leads 16, and/or MRI modality 54. Forexample, the MRI compatibility information may include a date on whichAIMD 14 was implanted in patient 12, a date on which any revision wasmade to AIMD 14, an implant location of AIMD 14, or a name and/orcontact information of a physician who implanted AIMD 14 or manages careof patient 12. In some examples, the MRI compatibility information mayalso include a serial number, registration number, or model number ofAIMD 14 or contact information for the manufacturer of AIMD 14.

The MRI compatibility information may additionally, or alternatively,include information regarding leads 16 (and optionally, if present, leadextensions or adapters), such as, for example, a date on which leads 16were implanted in patient 12, a date on which any revision was made toleads 16, an implant location of leads 16, an indication of the presenceof an abandoned, broken or damaged lead 16, a serial number,registration number, or model number of leads 16, or an impedance of atleast one of leads 16.

Additionally, or alternatively, the MRI compatibility information mayinclude information regarding MRI modality 54. In some examples, AIMD 14may be compatible with certain types of MRI scanners, but may not becompatible with other types of MRI scanners. For example, the AIMD 14may be compatible with an MRI scanner 55 that produces a magnetic fieldof a certain approximate field strength level (e.g., 1.5 T) or may becompatible with an MRI scanner 55 that has a certain type of body coil.To determine compatibility between AIMD 14 and MRI scanner 55, theprocessor may automatically acquire information regarding the MRIscanner 55, such as the model number, registration number, or serialnumber of MRI scanner 55, a manufacturer of MRI scanner 55, a body coiltype of MRI scanner 55, e.g., single or multichannel, or the like. Insome examples, the MRI compatibility information regarding MRI modality54 may also include a magnetic field magnitude produced by MRI scanner55.

In some examples, the MRI compatibility information may includeinformation regarding a presence of another IMD implanted in patient 12and, optionally, MRI compatibility information about the other IMD.

In some examples, the processor may not obtain MRI compatibilityinformation regarding the MRI modality 54 to use when determiningwhether AIMD 14 is compatible with MRI modality 54. For example, theprocessor may determine that AIMD 14 is not compatible with any MRImodality 54 or that AIMD 14 is compatible with substantially all MRImodalities 54 (i.e., AIMD 14 is MRIS) based on MRI compatibilityinformation regarding AIMD 14 and/or leads 16. However, when theprocessor determines that AIMD 14 is compatible with an MRI modality 54having certain characteristics or operating parameters (i.e., that AIMD14 is MRICS), the processor may automatically obtain informationregarding MRI modality 54 to use in determining compatibility betweenAIMD 14 and the specific MRI modality 54, e.g., based on whether the MRImodality 54 has those characteristics or operating parameters.

As described above with respect to FIG. 4, different aspects of the MRIcompatibility information may be stored in memory or a database ofdifferent devices within system 50. For example, MRI compatibilityinformation regarding AIMD 14 may be stored in memory 26 of AIMD 14,memory 36 of patient programmer 62 or clinician programmer 64, AIMD dataserver 60, patient data archive 56, or combinations thereof. Similarly,MRI compatibility information regarding leads 16 may be stored in memory26 of AIMD 14, memory 36 of patient programmer 62, memory 36 ofclinician programmer 64, AIMD data server 60, patient data archive 56,or combinations thereof. MRI compatibility information regarding MRImodality 54 may be stored in a memory of MRI modality 54, MRI dataserver 58, or combinations thereof.

Although not shown in FIG. 6, in some examples, in addition to obtainingMRI compatibility information automatically from at least two sources(92), the processor may obtain information input by a user, such aspatient 12 or a MRI facility staff person or technician, or anothermedical caregiver. For example, patient 12 may know and remember atleast some of the AIMD information or may possess a patientidentification or information card with AIMD information printed on thecard. Patient 12 may input the information when prompted by theprocessor (e.g., via patient information terminal 52) or may provide theinformation to an MRI technician, clinician, or MRI facility staffperson, who then enters the data into an appropriate device of system50. In other examples, patient 12 may possess AIMD CompatibilityDocumentation produced by a health care provider such as an implanting,managing, or referring physician, which may provide at least some of theMRI compatibility information. Patient 12 may input the information fromthe AIMD Compatibility Documentation when prompted by the processor(e.g., via patient information terminal 52), or may provide theinformation to an MRI technician, clinician, or MRI facility staffperson to enter the AIMD data into the appropriate device of system 50when prompted by the processor.

Once the processor has obtained the MRI compatibility information (92),the processor may automatically analyze the MRI compatibilityinformation to determine whether the AIMD 14 is compatible with an MRImodality 54 (74). However, when the MRI compatibility information cannotbe obtained (72), such as when some of the necessary MRI compatibilityinformation is not stored in a device interrogated by the processor,further investigation may be necessary or advisable prior to authorizingor refusing the MRI scan (90).

The processor may first analyze information regarding AIMD 14 and leads16 to determine whether the MRI compatibility information indicates thatAIMD 14 is compatible with at least some MRI modalities 54 (i.e., thatAIMD 14 is MRICS) or that AIMD 14 is incompatible with substantially allMRI modalities 54. For example, when the MRI compatibility informationindicates a presence of an abandoned, orphaned, or broken lead 16 in thebody of patient 12, the processor may determine that patient 12 is not acandidate for an MRI scan by MRI modality 54. Similarly, an implantdate, model number, registration number, or serial number of AIMD 14 maybe utilized as a sort of threshold qualification in determining whetherthe AIMD 14 comprises MRICS hardware. For example, it may be known thatan AIMD 14 implanted prior to a certain date would be incompatible withan MRI modality 54. In this case, the processor may reject asMRI-incompatible a device with a manufacture or implant date prior to acertain date. Conversely, a model number, registration number, or serialnumber of AIMD 14 may indicate that the AIMD 14 is compatible withsubstantially all MRI modalities 54 or MRI modalities 54 having certainoperating parameters (e.g., certain magnetic field strengths). In thiscase, the processor may compare the model number, registration number,or serial number to a list of model, registration, or serial numbersassociated with AIMDs known to be compatible with a particular MRImodality. In some examples, the processor may execute an algorithm thatidentifies certain values or patterns of a model number, registrationnumber, or a serial number as corresponding to an AIMD that does or doesnot comprise MRICS or MRIS hardware. For example, the processor mayutilize the first four characters of a model number, registrationnumber, or serial number of AIMD 14 or leads 16 and compare these fourcharacters to a database including entries comprising the first fourcharacters of a plurality of AIMDs or leads. The processor may then makea determination of MRI compatibility of the AIMD 14 based on the resultsof the comparison of the characters of the serial number, registrationnumber, or model number with entries in the database.

In examples in which the processor determines that AIMD 14 is compatiblewith some MRI modalities 54, i.e., that AIMD 14 comprises MRICShardware, the processor may obtain MRI compatibility informationregarding the particular MRI modality 54 which is to be used to performthe MRI scan. The processor may then utilize the information regardingthe MRI modality 54 (e.g., information regarding MRI scanner 55) todetermine whether the AIMD 14 is compatible with the particular MRImodality 54. For example, the processor may determine that AIMD 14 isconditionally compatible with a MRI scanner 55, e.g., AIMD 14 iscompatible with an MRI scanner 55 that produces a magnetic fieldcompatible with AIMD 14. The processor may obtain information relatingto a magnetic field produced by MRI scanner 55 from MRI modality 54 orMRI data server 58 and may utilize this information to determine whetherthe AIMD 14 is compatible with the particular MRI scanner 55.

In examples in which the processor determines that AIMD 14 is notcompatible with MRI modality 54, the processor may output an indicationthat AIMD 14 is incompatible with MRI modality 54 and the MRI scan isrefused (88). For example, the processor may direct a display or otheruser interface medium to convey such an indication to a user in avisible, audible or other effective manner. In some examples, theprocessor may not determine that AIMD 14 is incompatible with MRImodality 54, but the MRI compatibility information that the processoruses to make the compatibility determination may be incomplete, unclear,or conflicting. In these cases, the processor may alert a user of thequestionable information, and may refuse to authorize an MRI scan untilthe information is corrected or provided.

In some examples, once the processor determines that AIMD 14 iscompatible with MRI modality 54, the processor may optionally performone or more safety checks to confirm compatibility between AIMD 14 andMRI modality 54. Two exemplary safety checks are illustrated in FIG. 6as steps (76) and (78). Although these two safety checks are illustratedas separate steps from determining compatibility between AIMD 14 and MRImodality 54, the steps fall within a broad interpretation of determiningcompatibility between AIMD 14 and MRI modality 54.

In some examples, the processor optionally may confirm that hardware ofAIMD 14 is MRI conditionally safe (MRICS) or MRI safe (MRIS) (76). Theprocessor may confirm that AIMD 14 comprises MRICS or MRIS hardware byobtaining information including, for example, the implant date of AIMD14, the model number, registration number, or serial number of AIMD 14and/or leads 16, or the like. In some example, the processor may havealready obtained the information as part of step (92) and the processormay utilize the information at this time to confirm AIMD 14 comprisesMRICS or MRIS hardware. As described above, such information may bestored in memory 26 of AIMD 14, memory 36 of patient programmer 62 orclinician programmer 64, patient data archive 56, or AIMD data server60. Additionally or alternatively, the serial number, registrationnumber, or model number of AIMD 14 may be provided on the patient IDcard, and patient 12 may input the serial, registration, or model numbervia patient information terminal 52 or provide the serial or modelnumber to a user, who enters the information in an appropriate device.The processor may use the serial number, registration number, or modelnumber of AIMD 14 and/or leads 16 to retrieve information regarding AIMD14 or leads 16 from an AMD data server 60, or the like.

In some examples, the processor may execute an algorithm that identifiescertain values or patterns of a model number, registration number, or aserial number as corresponding to an AIMD that does or does not compriseMRICS or MRIS hardware. For example, the processor may utilize the firstfour characters of a model number, registration number, or serial numberof AIMD 14 or leads 16 and compare these four characters to a databaseincluding entries comprising the first four characters of a plurality ofAIMDs or leads. The processor may then make a determination of MRIcompatibility of the AIMD 14 based on the results of the comparison ofthe characters of the serial number, registration number, or modelnumber with entries in the database.

In some examples, the processor may perform a software lockout check toconfirm whether AIMD 14 comprises MRICS or MRIS hardware. For example,upon implant of AIMD 14 and leads 16 in patient 12, an implantingphysician or another user may communicate the serial number of AIMD 14,serial number of leads 16, and the implant location to a manufacturer ofAIMD 14 or a third party, such as a third party that maintains MRICS orMRIS information for various AIMDs. The manufacturer or third party maydetermine whether the system is MRICS or MRIS based on the serialnumbers and the implant location. In some examples, the manufacturer orthird party may store the MRICS information for the system in a databaseon a server, e.g., AIMD data server 60 or patient data archive 56. Thesoftware lockout check, then, may include obtaining this informationfrom the AIMD data server 60 or patient data archive 56. In someexamples, the processor may also evaluate implant information such aslead location or the presence of abandoned leads to confirm that AIMD 14comprises MRICS hardware. In some examples, the implant information maybe stored in memory 26 of IMD 16 or memory 36 of patient programmer 62and may be retrieved by the processor.

When the processor completes the step of confirming whether AIMD 14comprises MRICS or MRIS hardware but determines that AIMD 14 does notcomprise MRICS hardware, the processor may generate a notification thatAIMD 14 is not compatible with the MRI scanner 55 and patient 12 willnot undergo an MRI scan (88).

However, when the processor confirms that AIMD 14 comprises MRICS orMRIS hardware (76), the processor may evaluate MRI compatibilityinformation regarding an implant location of AIMD 14 and leads 16 toconfirm that the implant locations permit an MRI scan (78). In someexamples, the implant location of AIMD 14 and/or leads 16 may be storedin memory in AIMD 14, external programmer 20, patient data archive 56,AIMD data server 60, or the like. In some examples, the processor mayautomatically obtain the implant location information from one or moreof patient programmer 62, AIMD 14, clinician programmer 64, AIMD dataserver 60, or patient data archive 56, while in other examples, a usermay input the implant location information, e.g., via patientinformation terminal 52, or the like.

In some examples, a user may determine the AIMD implant location orMRICS hardware exceptions by x-ray images or fluoroscopic images. Forexample, the x-ray or fluoroscopic images may show an abandoned lead,i.e., a lead that is not coupled to an IMD, or a lead that is broken ordamaged. The AIMD implant location or MRICS hardware exceptions (e.g.,abandoned leads) may then be stored in a memory of a device in system50, as described above.

Some locations at which AIMD 14 or leads 16 are implanted may precludepatient 12 from having an MRI scan. For example, leads 16 may beimplanted proximate to a particular anatomical target of the patient 12,or near a target that does not correspond to a customary implantlocation. Similarly, leads 16 that are orphaned, i.e., unconnected to astimulator, or damaged may preclude patient 12 from having an MRI scandue to potential overheating of the leads 16. When the processordetermines that AIMD 14 is implanted in a location that precludes an MRIscan or patient 12 has implanted leads 16 that have become damaged ororphaned (78), the processor may generate a notification to a user thatpatient 12 should not undergo an MRI scan (88).

When the processor determines that the AIMD 14 is implanted in alocation that does not preclude an MRI scan and patient 12 does not haveany implanted leads that are damaged or orphaned, the processor mayproceed to transmit an instruction to processor 24 of AIMD 14 to preparefor an AIMD scan or may prompt the user to prepare AIMD 14 for an MRIscan (80). In some examples, the processor may transmit an instructionto processor 24 to perform a lead impedance test for each lead 16A, 16B(and, if present, any lead extensions or adaptors) that is coupled toAIMD 14. The impedance test may be an open/close test that indicateswhether any of leads 16 includes a broken conductor, which may producean open circuit. The impedance test also may indicate presence ofcontact between two conductors, which results in a short circuit. Insome examples, when the impedance test indicates an open circuit or ashort circuit, processor 24 may transmit an indication to the processor,which may then generate a notification to the user that patient 12cannot undergo an MRI scan (88).

However, when the impedance test indicates that the leads 16 arefunctional and AIMD 14 is functioning correctly, the processor mayproceed to ensure that AIMD 14 is in an MRICS mode. In some examples,AIMD 14 may permanently be in an MRICS mode, and the processor may nottransmit any instruction to processor 24 adjust AIMD 14 in any way. Inother examples, the processor may transmit an instruction to processor24 to enter an MRI mode, e.g., using patient programmer 62 or clinicianprogrammer 64. The MRICS mode may include features that prevent AIMD 14from inadvertently delivering stimulation to patient 12 during the MRIscan. For example, the MRICS mode may place AIMD 14 in a low power statein which AIMD 14 does not deliver stimulation, but which preventsaccidental provision of stimulation to patient 12. In some examples,AIMD 14 may be providing life-sustaining therapy, and may not be able tobe placed in an MRICS mode in which stimulation is interrupted. In theseexamples, the processor may indicate this fact to the user, and the usermay inform patient 12 that he or she should not undergo an MRI scan(88).

When the processor has prepared AIMD 14 for the MRI scan (80), theprocessor may transmit instructions to MRI modality 54 to prepare theMRI scanner 55 or may prompt the user to prepare the MRI scanner 55 forscanning (82). Preparation of the MRI scanner 55 for scanning mayinclude, for example, scan parameter validation, e.g., setting orconfirming MRI scan parameters according to which the MRI scanner 55will scan patient 12. The MRI scan parameters may include, for example,a magnetic field magnitude and a gradient strength. A magnetic fieldthat is too high may not be suitable for a patient 12 having an AIMD 14implanted in his or her body, as described above. Similarly, a gradientstrength that is too large may not be suitable for a patient having anAIMD 14 implanted in his or her body.

In some examples, the processor may transmit an instruction or set ofinstructions that instruct MRI modality 54 to set MRI scan parameters.In other examples, a user, such as a clinician or MRI technician, may beresponsible for setting and confirming the MRI scan parameters. The usermay confirm that the MRI scan parameters adheres to the guidelines ofthe AIMD 14 implanted in patient 12. In some examples, the user mayconsult a radiologist or a manufacturer of AIMD 14 for assistance insetting the MRI scan parameters. For example, the user may contact themanufacturer of AIMD 14 via a phone call or a website of themanufacturer.

The processor or the user may also confirm that the RF coil of the MRIscanner 55 is compatible with AIMD 14. For example, AIMD 14 may becompatible only with an MRI scanner 55 that include a single channel RFcoil, and may not be compatible with an MRI scanner 55 that includes amultiple channel RF coil. As another example, a quadrature bird cage RFcoil may function in linear mode and cause AIMD 14 to be exposed to anexcessive magnetic field.

In some examples, the MRI scanner 55 may include an AIMD mode thatassures stringent internal limits on operation of the MRI scanner 55 toprevent AIMD 14 from being exposed to excessive magnetic fields. Theprocessor or the user may configure the MRI scanner 55 in the AIMD modeprior to scanning patient 12. Once the MRI scanner 55 is prepared forscanning (82), a user may initiate the MRI scan of patient 12 (84).

Finally, regardless of whether the previous steps of the techniqueresulted in an MRI scan of patient 12 or a notification that patient 12cannot undergo an MRI scan, the information collected in the precedingsteps and the results of the determinations made by the processor may bearchived in patient data archive 56 (86). Additionally or alternatively,the patient data archive 56 may serve as a location from which MRIcompatibility information may be obtained at a later time. As describedabove, patient data archive 56 may comprise a database of informationregarding a plurality of patients, which may be maintained by the MRIfacility, an organization with which the MRI facility is associated, ora third party. In some examples patient data archive may include anelectronic and/or printed copy of the information collected and thedeterminations made by system 50 or a user. For example, some or all ofthe information collected in the various steps of the techniqueillustrated in FIG. 6 may be stored in a Digital Imaging andCommunications in Medicine (DICOM) Modality Worklist record, which maybe subsequently available to MRI technicians or other clinician.

FIG. 7 is a flow diagram that illustrates another technique according towhich a determination of compatibility between an AIMD 14 and a MRImodality 54 may be made. While the technique illustrated in FIG. 6 wasdirected to an automated or partially automated technique executed by aprocessor for determining compatibility between an AIMD 14 and an MRImodality 54, the technique illustrated in FIG. 7 is directed to apatient-centric technique for obtaining information relevant tocompatibility between an AIMD 14 and an MRI modality 54. In someexamples, the patient-centric technique illustrated in FIG. 7 may bemore efficient than another technique for determining compatibilitybetween an AIMD 14 and an MRI modality 54. For example, thepatient-centric technique illustrated in FIG. 7 may allow a patient 12to enter information regarding an AIMD 14 implanted in the body of thepatient 12 and determine whether the AIMD is compatible with an MRImodality 54. Additionally, a patient-centric technique may empower apatient 12 to better appreciate and understand why the patient 12 doesor does not qualify for an MRI scan, and may enable the patient 12 tomake more informed decisions regarding his or her care. In someexamples, the results of the patient-centric technique illustrated inFIG. 7 may be verified by a physician prior to performing an MRI scan ormay be supplemented by another technique illustrated herein to verifythat the information provided by the patient 12 is correct andconsistent.

The technique illustrated in FIG. 7 may be primarily implemented in apatient information terminal 52. As described above, patient informationterminal 52 may include a laptop computer, a desktop computer, or aworkstation that executes a software program or accesses a website thatguides the patient to enter information pertinent to the determinationof compatibility of AIMD 14 and AIMD modality 54. Hence, patientinformation terminal 52 may be a hardware device that resides in an MRIfacility or clinic for direct access by a patient 12, and/or a hardwaredevice that includes, is coupled to or otherwise provides a web serveror other remote server that presents a user interface for remote accessby the patient. Patient 12 may enter the MRI compatibility informationvia patient information terminal 52 at his or her convenience prior toan MRI appointment. For example, patient 12 may access a websitepresented by a web server from a personal computer located at his or herhome or another location. Web pages provided by the web server maypresent a front end interface for a patient 12 operating a patientcomputer to obtain remote access to patient information terminal 52,e.g., via network 66. Alternatively, the patient may access patientinformation terminal 52 directly in the MRI facility or clinic. Thewebsite may prompt patient 12 to enter MRI compatibility information,and may guide patient 12 through entry of the MRI compatibilityinformation. For example, the website may include illustrations or otheraids that assist patient 12 in retrieving the MRI compatibilityinformation from his or her patient ID card, AIMD CompatibilityDocumentation, patient programmer 62, or AIMD 14 via the patientprogrammer 62. In some cases, the website may be presented by MRIcompatibility web server 68 or by some other web server.

Patient information terminal 52 may execute a software program or accessa website such as a website provided by MRI compatibility server 68,which provides instructions regarding the MRI compatibility informationto be obtained from patient 12. For example, patient informationterminal 52 may execute an application program that executes locally onpatient information terminal 52 or remotely via network 66 and promptspatient 12 to input pertinent information. The program may additionallyevaluate the information entered by patient 12 and present subsequentprompts to patient 12 based on previously entered information. In someexamples, the program executed by patient information terminal 52 mayautomatically determine whether the AIMD 14 is compatible with an MRImodality 54, while in other examples, the program may provide an outputthat patient 12 may provide to a user, such as a clinician or MRItechnician, who may then determine whether AIMD 14 is compatible withthe MRI modality 54.

In the example technique illustrated in FIG. 7, patient informationterminal 52 first obtains MRI compatibility information from patient 12via patient information terminal 52 (102). As described above, the MRIcompatibility information may include, for example, a date on which AIMD14 was implanted in patient 12 or a date on which a revision was made toAIMD 14. The revision may include, for example, a subsequent surgicalprocedure to repair or modify AIMD 14 or a surgical procedure toreplace, modify, or implant leads 16 that connect to AIMD 14. In someexamples, the MRI compatibility information may include an indication ofa presence of another IMD implanted in patient 12. The MRI compatibilityinformation also may include a name and/or phone number of a physicianwho implanted AIMD 14 in patient 12 or who manages therapy provided topatient 12 by AIMD 14. In some examples, the MRI compatibilityinformation also includes a manufacturer of AIMD 14 and/or leads 16,contact information for the manufacturer, or a serial number,registration number, or model number of AIMD 14 and/or leads 16. The MRIcompatibility information may optionally also include informationregarding a location at which AIMD 14 is implanted in patient 12, suchas, for example, torso, right or left leg, cranium, or more specificlocation information.

In some examples, at least some of the MRI compatibility information maybe stored on a patient ID card or AIMD Compatibility Documentation.Patient 12 may carry the patient ID card as a reference for theinformation contained thereon, and may refer to the patient ID whenentering the MRI compatibility information via patient informationterminal 52.

AIMD Compatibility Documentation may also contain at least some of theinformation discussed above in this disclosure. The AIMD CompatibilityDocumentation may have been produced recently by a health care provider,such as an implanting, managing, or referring physician, based on thehealth care provider's knowledge of the MRI compatibility of AIMD 14.AIMD Compatibility Documentation may be possessed by patient 12 andreferred to when entering pertinent data into patient informationterminal 52.

In some examples, at least some of the MRI compatibility information maybe stored in memory 36 of patient programmer 62. As described above,patient 12 may use patient programmer 62 to interact with AIMD 14. Insome examples, patient programmer 62 may allow patient 12 to selectamong a number of available therapy programs stored in memory 36 ofpatient programmer or memory 26 of AIMD 14 or to adjust one or moretherapy parameter of a therapy program within a range determined by aclinician and stored in memory 26 or memory 36. Patient programmer 62may be carried by patient 12 and may be portable such that patientprogrammer 62 may accompany patient 12 through his or her daily routine.In some examples, the patient 12 may retrieve information from memory 36of patient programmer 62 via user interface 38 of patient programmer 62.In some examples, the information stored in memory 36 of patientprogrammer 62 may include, for example, one or more of implant date orrevision date, physician name and/or telephone number, manufacturername, model number, registration number, or serial number of AIMD 14and/or leads 16, an implant location, compatible magnetic fieldstrength, or the like.

In other examples, at least some of the MRI compatibility informationmay be stored in memory 26 of AIMD 14. Information stored in memory 26may be retrieved by via patient programmer 62 or clinician programmer64, e.g., via wireless telemetry. Patient 12 may then view the MRIcompatibility information and enter the information via patientinformation terminal 52. Memory 26 may store, for example, one or moreof implant date or revision date, physician name and/or telephonenumber, manufacturer name, model number, registration number, or serialnumber of AIMD 14 and/or leads 16, implant location, compatible magneticfield strength, or the like. In some examples, at least some of theinformation may be stored in memory 26 of AIMD 14 while at least some ofthe information is stored in memory 36 of patient programmer 62. Some ofthe same information may be stored in memory 26 and memory 36 in somecases.

In some examples, patient information terminal 52 may be configured tosupplement the MRI compatibility information provided by patient 12 withMRI compatibility information retrieved from another device in system50, such as, for example, AIMD data server 60, MRI data server 58,patient data archive 56, MRI modality 54, or the like. In some cases,when patient 12 indicates that he or she does not know or is unable toobtain MRI compatibility information requested by patient informationterminal 52, the software program or web page executed by patientinformation terminal 52 may automatically attempt to obtain therequested information from one or more of AIMD data server 60, MRI dataserver 58, patient data archive 56, and/or MRI modality 54. In otherexamples, patient information terminal 52 may not attempt to retrieveMRI compatibility information from another device of system 50, and mayinstead indicate to patient 12 that an MRI compatibility determinationcannot be made with the available information and further investigationis required (90).

Once the MRI compatibility information has been collected (102), patientinformation terminal 52 determines compatibility of AIMD 14 and an MRImodality 54 (104). In some examples, patient information terminal 52 maynot have collected any information regarding a particular MRI modality54 at this time. Instead, patient information terminal 52 may provide ageneral indication to patient 12 based on the MRI compatibilityinformation regarding AIMD 14 and/or leads 16 whether AIMD 14 is MRIcompatible. For example, patient information terminal 52 may analyze theimplant date of AIMD 14 and/or leads 16 to determine whether AIMD is MRIcompatible. For example, it may be known that an AIMD 14 implanted priorto a certain date would not be MRI compatible (i.e., that the AIMD wouldnot comprise MRICS or MRIS hardware).

In some examples, patient information terminal 52 may utilize a serialnumber, registration number, or model number of AIMD 14 and/or leads 16coupled to AIMD 14 to determine whether AIMD 14 is MRI compatible.Patient information terminal 52 may use the serial number, registrationnumber, or model number of AIMD 14 and leads 16 to retrieve informationregarding MRI compatibility of AIMD 14 or leads 16 from a spreadsheet ordatabase of serial number or model numbers and corresponding MRIcompatibility or MRI incompatibility. The spreadsheet or database may bestored in, for example, patient information terminal 52 or MRIcompatibility web server 68. In some examples, patient informationterminal 52 may utilize the serial number, registration number, or modelnumber to retrieve data regarding the AIMD from AIMD data server 60.

In some examples, patient information terminal 52 may execute analgorithm that identifies certain values or patterns of a model number,registration number, or a serial number as corresponding to an AIMD 14that does or does not comprise MRICS or MRIS hardware. For example,patient information terminal 52 may utilize the first four characters ofa model number, registration number, or serial number of AIMD 14 orleads 16 and compare these four characters to a database includingentries comprising the first four characters of a plurality of AIMDs orleads. Patient information terminal 52 may then make a determination ofMRI compatibility of the AIMD 14 based on the results of the comparisonof the characters of the serial number, registration number, or modelnumber with entries in the database.

Based on the MRI compatibility information regarding AIMD 14 and/orleads 16, patient information terminal 52 may determine whether AIMD 14is compatible with substantially all MRI modalities 54 (i.e., is MRIsafe), whether AIMD 14 is compatible with MRI modalities 54 havingcertain operating parameters or characteristics (i.e., is MRIconditionally safe), or whether AIMD 14 is incompatible withsubstantially all MRI modalities (104). When patient informationterminal 52 determines that AIMD 14 is incompatible with substantiallyall MRI modalities, patient information terminal 52 may generate anddisplay a notification to patient 12 that he or she does not qualify foran MRI scan (88). When patient information terminal 52 determines thatAIMD 14 is compatible with at least some MRI modalities (54), patientinformation terminal 52 may proceed to confirm that AIMD 14 comprisesMRICS or MRIS hardware (76).

In some examples, AIMD 14 may be compatible with certain types of MRImodalities, but may not be compatible with other types of MRI modalities(i.e., may be MRI conditionally safe). To determine compatibilitybetween AIMD 14 and an MRI modality 54 with more specificity, patientinformation terminal 52 may obtain MRI compatibility informationregarding the MRI modality 54 prior to determining MRI compatibility ofAIMD 14 (104). For example, patient information terminal 52 may obtaininformation regarding MRI modality 54 via network 66 from MRI modality54, MRI data server 58, or the like. The MRI compatibility informationregarding MRI modality may include, for example, the type of MRI scanner55, the RF coil type, and the like. In some examples, the type of MRIscanner 55 may include the model number and manufacturer of the MRIscanner 55. In other examples, the type of MRI scanner 55 may includethe magnet type and the magnetic field strength produced by the MRIscanner 55. For example, an AIMD 14 may be compatible with an MRIscanner 55 that produces a magnetic field having a magnitude of 1.5 T.In other examples, the magnetic field with which AIMD 14 is compatiblemay be different. The RF coil type may include an indication of whetherthe RF coil is a single channel or a multiple channel RF coil.

Patient information terminal 52 may compare the information regardingMRI modality 54 and the information regarding AIMD 14 to determinewhether AIMD 14 is compatible with the MRI modality 54. Patientinformation terminal 52 may automatically determine whether AIMD 14 andMRI modality 54 are compatible based on the MRI modality information andthe AIMD information.

For example, patient information terminal 52 may compare a magneticfield strength with which AIMD 14 is compatible to a magnetic field,e.g., a magnetic field or a magnetic field produced by a particular setof MRI scan parameters, produced by MRI scanner 55. When patientinformation terminal 52 determines that AIMD 14 is not compatible withMRI modality 54, patient information terminal 52 outputs an indicationthat AIMD 14 is incompatible with MRI modality 54 and the MRI scan isrefused (88). In some examples, patient information terminal 52 may notdetermine that AIMD 14 is incompatible with MRI modality 54, but one orboth of the AIMD information or the MRI modality information may beincomplete, unclear, or conflicting. In these cases, patient informationterminal 52 may alert patient 12 of the questionable information, andmay refuse to authorize MRI scan until the information is corrected orprovided.

In some examples, once patient information terminal 52 determines thatAIMD 14 is compatible with MRI modality 54, patient information terminal52 optionally may proceed to confirm that AIMD 14 comprises MRICS orMRIS hardware (76) as a safety measure. Patient information terminal 52may confirm that the AIMD 14 comprises MRICS or MRIS hardware bycollecting information including, for example, the implant date of AIMD14, the model number, registration number, or serial number of AIMD 14and/or leads 16, or the like. In some example, patient informationterminal 52 may have obtained at least some of this information whenobtaining MRI compatibility information (102), while in other examples,patient information terminal 52 may prompt patient 12 to enter at leastsome of this information at this time, or may obtain at least some ofthe information from another device in system 50 at this time. In someexamples, the implant date may be utilized as a sort of thresholdqualification in determining whether the implant comprises MRICS or MRIShardware. For example, it may be known that an AIMD 14 implanted priorto a certain date would not have included MRICS or MRIS hardware. Insome examples, patient information terminal 52 may utilize the serialnumber, registration number, or model number of AIMD 14 and leads 16 toretrieve information regarding AIMD 14 or leads 16 from an AMD dataserver 60, a manufacturer's website, a third party website, or the like.

In some examples, patient information terminal 52 may execute analgorithm that identifies certain values or patterns of a model number,registration number, or a serial number as corresponding to an AIMD 14that does or does not comprise MRICS or MRIS hardware. For example,patient information terminal 52 may utilize the first four characters ofa model number, registration number, or serial number of AIMD 14 orleads 16 and compare these four characters to a database includingentries comprising the first four characters of a plurality of AIMDs orleads. Patient information terminal 52 may then make a determination ofMRI compatibility of the AIMD 14 based on the results of the comparisonof the characters of the serial number, registration number, or modelnumber with entries in the database.

The information used by patient information terminal 52 to confirm thatAIMD 14 comprises MRICS or MRIS hardware also may include a softwarelockout check. In some examples, upon implantation of AIMD 14 and leads16, an implanting physician or another user may communicate the serialnumber of AIMD 14, serial number of leads 16, and the implant locationto a manufacturer of AIMD 14 or a third party, such as a third partythat maintains MRICS information for various AIMDs. The manufacturer orthird party may determine whether AIMD 14 is MRICS or MRIS based on theserial numbers and the implant location. In some examples, themanufacturer or third party may issue a MRICS card that indicates thatAIMD 14 and leads 16 do or do not form an MRICS system to patient 12,may issue a patient ID card with an indication that AIMD 14 and leads 16do or do not form an MRICS or MRIS system, or may store the MRICSinformation for the system in a database on a server, e.g., AIMD dataserver 60 or patient data archive 56. The software lockout check, then,may include obtaining this information from the MRICS card, the patientID card, or the database. In some examples, a manufacturer of AIMD 14may provide a blank MRICS card to the implanting physician, who may fillout the MRICS card with, for example, a serial number of AIMD 14 and/orleads 16, and implant location of AIMD 14 and/or leads 16, or anindication of whether the system formed by AIMD 14 and leads 16 is MRICSor MRIS. When patient information terminal 52 determines that AIMD 14does not comprise MRICS or MRIS hardware, patient information terminal52 may generate a notification that AIMD 14 is not compatible with theMRI modality 54 and patient 12 will not undergo an MRI scan (88).

When patient information terminal 52 determines that AIMD 14 does, infact, comprise MRICS or MRIS hardware, patient information terminal 52optionally may proceed to prompt patient 12 to input the AIMD locationand any MRICS hardware exceptions (78) as another safety check. In someexamples, patient 12 may determine the AIMD implant location or MRICShardware exceptions by retrieving information stored in memory 26 ofAIMD 14 or memory 36 of patient programmer 62 or by a phone call to themanufacturer of AIMD 14. In other examples, patient information terminal52 may retrieve the information from AIMD data server 60 or by accessinga website of the manufacturer. In some examples, retrieving theinformation from the manufacturer may require the serial number of AIMD14, and may only work when AIMD 14 has been registered with themanufacturer.

Some locations at which AIMD 14 or leads 16 are implanted may precludepatient 12 from having an MRI scan. For example, leads 16 may beimplanted proximate to a particular anatomical target of the patient 12,or near a target that does not correspond to a customary implantlocation. Similarly, leads 16 that are orphaned, i.e., unconnected to astimulator, or damaged may preclude patient 12 from having an MRI scandue to potential overheating of the leads 16. When patient informationterminal 52 determines that AIMD 14 is implanted in a location thatprecludes an MRI scan or patient 12 has implanted leads 16 that aredamaged or orphaned, patient information terminal 52 may generate anotification to a user that patient 12 cannot undergo an MRI scan (88).

Regardless of whether the previous steps of the technique resulted in anMRI scan of patient 12 or a notification that patient 12 cannot undergoan MRI scan, the information collected in the preceding steps and theresults of the determinations made by patient information terminal 52may be archived in patient data archive 56 (86). As described above,patient data archive 56 may comprise database of information regarding aplurality of patients, which may be maintained by the MRI facility, anorganization with which the MRI facility is associated, or a thirdparty. In some examples patient data archive may include an electronicand/or printed copy of the information collected and the determinationsmade by system 50 or a user. In some examples, some or all of theinformation collected in the various steps of the technique illustratedin FIG. 7 may be stored in a Digital Imaging and Communications inMedicine (DICOM) Modality Worklist record, which may be subsequentlyavailable to MRI technicians or other clinician.

While the examples illustrated in FIGS. 5-7 have concerned obtaining MRIcompatibility information and determining compatibility between an AIMD14 and an MRI modality based on the MRI compatibility information, insome examples, the MRI compatibility information may have beenpreviously obtained. For example, it may be desired that patient 12 hasthe ability to determine compatibility of AIMD 14 with an MRI modality54, and when it is determined that AIMD 14 is compatible with the MRImodality 54, to configure AIMD 14 in a MRI conditionally safe operatingmode. To facilitate such a MRI compatibility determination andconfiguration of AIMD 14, patient 12 may utilize a patient programmer62. As described above, a patient programmer 62 may be a portable devicethat generally accompanies the patient throughout a daily routine.Patient 12 may possess patient programmer 62 and utilize the patientprogrammer 62 to interact with AIMD 14, e.g., to retrieve informationfrom AIMD 14 or to program AIMD 14 within limits prescribed by amanaging physician.

In some examples, patient programmer 62 may implement software,hardware, firmware, or combinations thereof that enable patientprogrammer 62 to automatically obtain from memory 26 of AIMD 14 and/ormemory 36 of patient programmer 62 information regarding MRIcompatibility of AIMD 14. In some examples, patient programmer 62 mayutilize the MRI compatibility information to make a determination of MRIcompatibility of AIMD 14. Patient programmer 62 may then display theresults of the determination of MRI compatibility via user interface 38,or may communicate the MRI compatibility determination results toanother computing device in system 50 (FIG. 4), such as patientinformation terminal 52, clinician programmer 64, MRI modality 54, orthe like, for display to a user, such as patient 12, a clinician, or anMRI technician. In other examples, patient programmer 62 may communicatethe MRI compatibility information to another computing device incomputing system 50, and the other computing device may make the MRIcompatibility determination. Additionally, patient programmer 62 mayimplement software, hardware, firmware, or combinations thereof thatenable the programmer 62 to instruct AIMD 14 to enter an MRIconditionally safe operating mode. FIG. 8 illustrates an example of atechnique that may be implemented by the patient programmer. Thetechnique illustrated in FIG. 8 will be described with reference to AIMD14 of FIG. 2 and patient programmer 62 of FIG. 4, which may includecomponents similar to those of external programmer 20 of FIG. 3.

According to the technique illustrated in FIG. 8, processor 34 ofpatient programmer 62 first obtains MRI compatibility information (112).In some examples, processor 34 of patient programmer 62 interrogatesAIMD 14 to retrieve MRI compatibility information stored in AIMD 14. Inparticular, the MRI compatibility information may be stored in memory 26of AIMD 14. As described above, memory 26 may store, for example, animplant date of AIMD 14 and/or leads 16, a revision date, if any, ofAIMD 14 and/or leads 16, or a name and/or phone number of a physicianwho implanted AIMD 14 or manages care of patient 12. In some examples,memory 26 may store an indication of a presence of another IMD implantedin patient 12. In some examples, memory 26 may store a manufacturer ofAIMD 14 and contact information for the manufacturer, a serial,registration, or model number or name of AIMD 14 and/or leads 16, and/ora magnetic field magnitude to which AIMD 14 can be exposed. Additionallyor alternatively, memory 26 may store information regarding an implantlocation of AIMD 14 and/or leads 16, an indication of the presence of anabandoned, broken, or damaged lead 16, or an impedance of one or more ofleads 16.

In some examples, in addition or as an alternative to interrogating AIMD14 to obtain the MRI compatibility information, processor 34 of patientprogrammer 62 may obtain MRI compatibility information stored in memory36 of patient programmer 62. Memory 36 of patient programmer 62 maystore any of the MRI compatibility information described above as beingstored in memory 26 of AIMD 14, or any other applicable MRIcompatibility information. For example, the MRI compatibilityinformation may be stored in memory 36 of programmer 62 as a result of aprevious interrogation of memory 26 of AIMD 14, or as a result ofstorage of the MRI compatibility information in memory 36 of programmer62 by a clinician or other caregiver. In some examples, some of the MRIcompatibility information may be stored in memory 26 of AIMD 14 and someof the compatibility information may be stored in memory 36 of patientprogrammer 62, and processor 34 may retrieve MRI compatibilityinformation from both sources.

The MRI compatibility information may have been programmed into memory26 of AIMD 14 and/or memory 36 of patient programmer 62 at the time ofmanufacture or upon implantation of AIMD 14 in patient 12. For example,the model number, registration number, or serial number of AIMD 14, amanufacturer of AIMD 14, contact information for the manufacturer, or amagnetic field magnitude to which AIMD 14 can be exposed may be storedin memory 26 and/or memory 36 at the time of manufacture of AIMD 14. Asanother example, at the time of implant of AIMD 14, the implantingphysician may program into memory 26 and/or memory 36 an implant date ofAIMD 14 and leads 16, a name and/or phone number of the implantingphysician, a serial, registration, or model number or name of AIMD 14and/or leads 16, an implant location of AIMD 14 and/or leads, or thelike.

In some examples, when a change is made to AIMD 14 or leads 16, the MRIcompatibility information stored in memory 26 and/or memory 36 may beupdated. For example, an implanting physician may update the MRIcompatibility information stored in memory 26 and/or memory 36 when arevision is made to AIMD 14 or leads 16 or when a broken, abandoned, ordamaged lead 16 is discovered. In some examples, AIMD 14 mayautomatically update at least some of the MRI compatibility informationwhen AIMD 14 determines or discovers that the MRI compatibility haschanged, e.g., upon measuring an impedance of leads 16 and determiningthe impedance has changed from a previous measurement.

In examples in which processor 34 obtains MRI compatibility informationfrom AIMD 14, such as patient 12, processor 34 of patient programmer 62may generate an instruction requesting processor 24 of AIMD 14 totransmit the MRI compatibility information stored in memory 26 toprocessor 34 in response to an input from a user, such as patient 12.Processor 34 may then communicate the instruction via telemetry circuit40 to telemetry circuit 28 and processor 24 of AIMD 14. Processor 24 ofAIMD 14 then may retrieve the MRI compatibility information from memory26 and communicate the information via telemetry circuit 28 to telemetrycircuit 40 and, ultimately, processor 34 of patient programmer 20.

In some examples, once processor 34 of patient programmer 62 hasobtained the MRI compatibility information (112), processor 34 mayautomatically analyze the MRI compatibility information to determinewhether the AIMD 14 is compatible with an MRI modality 54 (114).However, when the MRI compatibility information cannot be obtained, suchas when some of the necessary MRI compatibility information is notstored in memory 26 of AIMD 14, processor 34 of patient programmer 62may output an indication via user interface 38 that furtherinvestigation is necessary prior to authorizing or refusing the MRI scan(90).

In examples in which sufficient MRI compatibility information is storedin memory 26 of AIMD 14 and/or memory 36 of patient programmer 62,processor 34 may utilize the MRI compatibility information to determinewhether the AIMD 14 is compatible with an MRI modality 54 (114). In someexamples, processor 34 may not have collected any information regardinga particular MRI modality 54 at this time. Instead, processor 34 mayprovide a general indication to patient 12 based on the MRIcompatibility information regarding AIMD 14 and/or leads 16 whether AIMD14 is compatible with an MRI modality 54 and, optionally, operatingparameters of MRI modality 54 with which AIMD 14 is compatible. Forexample, processor 34 of patient programmer 62 may analyze the implantdate of AIMD 14 and/or leads 16 to determine whether AIMD is MRIcompatible. For example, it may be known that an AIMD 14 implanted priorto a certain date would not be MRI compatible (i.e., would not compriseMRICS or MRIS hardware).

In some examples, processor 34 may utilize a serial number, registrationnumber, or model number of AIMD 14 and/or leads 16 coupled to AIMD 14 todetermine whether AIMD 14 is MRI compatible. Processor 34 may use theserial number, registration number, or model number of AIMD 14 and leads16 to retrieve information regarding MRI compatibility of AIMD 14 orleads 16 from a spreadsheet or database of serial numbers, registrationnumbers, or model numbers and corresponding MRI compatibility or MRIincompatibility. The spreadsheet or database may be stored in, forexample, memory 36 of patient programmer 62.

In some examples, processor 34 may execute an algorithm that identifiescertain values or patterns of a model number, registration number, or aserial number as corresponding to an AIMD 14 that does or does notcomprise MRICS or MRIS hardware. For example, processor 34 may utilizethe first four characters of a model number, registration number, orserial number of AIMD 14 or leads 16 and compare these four charactersto a database including entries comprising the first four characters ofa plurality of AIMDs or leads. Processor 34 may then make adetermination of MRI compatibility of the AIMD 14 based on the resultsof the comparison of the characters of the serial number, registrationnumber, or model number with entries in the database.

Based on the MRI compatibility information regarding AIMD 14 and/orleads 16, processor 34 of patient programmer 62 may determine whetherAIMD 14 is compatible with substantially all MRI modalities 54 (i.e., isMRI safe), whether AIMD 14 is compatible with MRI modalities 54 havingoperating parameters or characteristics (i.e., is MRI conditionallysafe), or whether AIMD 14 is incompatible with substantially all MRImodalities (114). For example, an AIMD 14 may be compatible with an MRImodality 54 that produces a magnetic field strength of approximately 1.5T, or some other specified level, or may be compatible with an MRImodality 54 having only certain types of RF coils, e.g., a singlechannel RF coil or a multichannel RF coil. When processor 34 determinesthat AIMD 14 is incompatible with substantially all MRI modalities,processor 34 may generate and display a notification via user interface38 to patient 12 that he or she does not qualify for an MRI scan (88).

When processor 34 of patient programmer 62 determines that AIMD 14 iscompatible with at least some MRI modalities (114), e.g., an MRImodality 54 producing a magnetic field of approximately 1.5 T, processor34 of patient programmer 62 may generate a notification of suchcompatibility (116). In some examples, the notification may includeinformation regarding the type of MRI modality 54 or operatingparameters of MRI modality with which AIMD 14 is compatible. In someexamples, processor 34 may cause the notification to be displayed orotherwise output via user interface 38 of patient programmer 62, whilein other examples, processor 34 may transmit the notification to anothercomputing device in system 50, e.g., patient information terminal 52,MRI modality 54, MRI compatibility web server 68, or the like, whichthen displays the notification to a user, such as patient 12, aclinician, or an MRI technician.

In some examples, when processor 34 determines that AIMD 14 iscompatible with at least some MRI modalities (114), processor 34 mayproceed to obtain information regarding the specific MRI modality 54which is to be used to perform the desired MRI scan on patient 12.Processor 34 may then utilize the information regarding the MRI modality54 (e.g., information regarding MRI scanner 55) to determine whether theAIMD 14 is compatible with the particular MRI modality 54. For example,processor 34 may determine that AIMD 14 is conditionally compatible withan MRI scanner 55, e.g., AIMD 14 is compatible with MRI scanner 55 whenMRI scanner 55 is configured to produce a magnetic field compatible withAIMD 14. Processor 34 may obtain information relating to a magneticfield produced by MRI scanner 55 from MRI modality 54 or MRI data server58 and may utilize this information to determine whether the AIMD 14 iscompatible with the particular MRI scanner 55. In some examples,processor 34 of patient programmer 62 is configured to communicate withMRI modality 54 or MRI data server 58 directly, via network 66, or viaan intermediary device, e.g., clinician programmer 64, to retrieve MRIcompatibility information regarding the particular MRI modality 54.

In examples in which processor 34 determines that AIMD 14 is notcompatible with the specific MRI modality 54, processor 34 may output anindication that AIMD 14 is incompatible with the MRI modality 54 and theMRI scan is refused (88). For example, processor 34 may direct a displayor other user interface medium to convey such an indication to a user ina visible, audible or other effective manner. In some examples,processor 34 may transmit the notification to another computing devicein system 50, e.g., patient information terminal 52, MRI modality 54,MRI compatibility web server 68, or the like, which then displays thenotification to a user, such as patient 12, a clinician, or an MRItechnician. In some examples, processor 34 may not determine that AIMD14 is incompatible with MRI modality 54, but the MRI compatibilityinformation that processor 34 uses to make the compatibilitydetermination may be incomplete, unclear, or conflicting. In thesecases, processor 34 may alert a user of the questionable information,and may refuse to authorize an MRI scan until the information iscorrected or provided.

In some examples, instead of processor 34 making the determination ofcompatibility between AIMD 14 and an MRI modality 54, processor 34 maytransmit the collected MRI compatibility information to anothercomputing device in system 50, which then makes the compatibilitydetermination. In some examples, the other computing device may bepatient information terminal 52, MRI modality 54, or MRI compatibilityweb server 68.

In some examples, processor 34 optionally may proceed to confirm thatAIMD 14 comprises MRICS or MRIS hardware (76). Processor 34 of patientprogrammer 62 may confirm that the AIMD 14 comprises MRICS or MRIShardware by collecting information including, for example, the implantdate of AIMD 14, the model number, registration number, or serial numberof AIMD 14 and/or leads 16, or the like. In some example, processor 34may have obtained at least some of this information when obtaining MRIcompatibility information (112), while in other examples, processor 34may obtain at least some of the information from memory 26 of AIMD 14and/or memory 36 of patient programmer 62 at this time. In someexamples, processor 34 may utilize the implant date as a sort ofthreshold qualification in determining whether the implant comprisesMRICS or MRIS hardware. For example, it may be known that an AIMD 14implanted prior to a certain date would not have included MRICS or MRIShardware. In some examples, processor 34 may utilize the serial number,registration number, or model number of AIMD 14 and leads 16 to retrieveinformation regarding AIMD 14 or leads 16 from an AMD data server 60, amanufacturer's website, a third party website, or the like. In someexamples, as described above, processor 34 may execute patternrecognition algorithm to determine based on a serial number,registration number, or model number whether AIMD 14 and/or leads 16comprise MRICS or MRIS hardware.

Processor 34 may also use a software lockout check to confirm that AIMD14 comprises MRICS or MRIS hardware. In some examples, upon implantationof AIMD 14 and leads 16, an implanting physician or another user maycommunicate the serial number of AIMD 14, serial number of leads 16, andthe implant location to a manufacturer of AIMD 14 or a third party, suchas a third party that maintains MRICS information for various AIMDs. Themanufacturer or third party may determine whether the system is MRICSbased on the serial numbers and the implant location. In some examples,the manufacturer or third party may issue a MRICS indication to theimplanting physician or a managing physician that indicates that AIMD 14and leads 16 do or do not form an MRICS or an MRIS system. Theimplanting physician or managing physician may then program a positiveor a negative MRICS or MRIS indication in AIMD 14 and/or patientprogrammer 62, which is stored in memory 26 of AIMD 14 and/or memory 36of patient programmer 62. The software lockout check, then, may includeobtaining this information from memory 26 of AIMD 14 and/or memory 36 ofpatient programmer 62. When processor 34 of patient programmer 62determines that AIMD 14 does not comprise MRICS or MRIS hardware,processor 34 may generate a notification via user interface 38 that AIMD14 is not compatible with the MRI modality 54 and patient 12 will notundergo an MRI scan (88).

When processor 34 determines that AIMD 14 does, in fact, comprise MRICSor MRIS hardware, processor 34 optionally may proceed to analyze theimplant location of AIMD 14 and/or leads 16 and any MRICS hardwareexceptions (78) as another safety check. In some examples, the implantlocation of AIMD 14 and/or leads 16 or MRICS hardware exceptions may bestored in memory 26 of AIMD 14 and/or memory 36 of patient programmer62.

Some locations at which AIMD 14 or leads 16 are implanted may precludepatient 12 from having an MRI scan. For example, leads 16 may beimplanted proximate to a particular anatomical target of the patient 12,or near a target that does not correspond to a customary implantlocation. Similarly, leads 16 that are orphaned, i.e., unconnected to astimulator, or damaged may preclude patient 12 from having an MRI scandue to potential overheating of tissue adjacent the leads 16. Whenprocessor 34 determines that AIMD 14 is implanted in a location thatprecludes an MRI scan or patient 12 has implanted leads 16 that aredamaged or orphaned, processor 34 may generate a notification via userinterface 38 to alert a user that patient 12 cannot undergo an MRI scan(88).

Once processor 34 of patient programmer 62 has determined that AIMD 14is compatible with an MRI modality 54, processor 34 may generate andtransmit a command to processor 24 of AIMD 14 to enter a MRIconditionally safe operating mode (118). Processor 24 may switch from anormal operating mode, in which stimulation generator 30 deliverstherapy to patient 12 via electrodes carried by leads 16, to the MRIsafe operating mode in response to the command received via telemetrycircuit 28 from processor 34 of programmer 62. In some examples, in theMRI conditionally safe operating mode, processor 24 may control thecomponents of AIMD 14 to be in a low power mode that provides sufficientfunctionality to the components, e.g., processor 24 and stimulationgenerator 30, to prevent stimulation therapy from accidentally beingdelivered to patient 12 during the MRI scan. In the MRI conditionallysafe operating mode, according to some examples, processor 24 of AIMD 14may remain awake but does not actively deliver electrical stimulation tothe patient. In examples in which AIMD 14 is MRI safe, AIMD 14 may notneed to be configured in a MRI conditionally safe operating mode, asAIMD 14 is safe for an MRI scan when operating in its normal operatingmode.

In addition to causing processor 24 and stimulation generator 30 toenter a low power mode in which therapy is not delivered to patient 12,the MRI conditionally safe operating mode may define certain conditionswhich must be complied with during the time that AIMD 14 is configuredin the MRI conditionally safe operating mode. For example, the MRIconditionally safe operating mode may define a time for which AIMD 14may be in the MRI conditionally safe operating mode, a position whichpatient 12 must assume during the time which AIMD 14 is in the MRIconditionally safe operating mode, a power or duration of the MRI scan,or the like. Upon entering MRI conditionally safe operating mode,processor 34 of patient programmer 62 may display the conditions viauser interface 38. In some examples, to increase a likelihood thatpatient 12 or a user, such as an MRI technician, comply with theconditions, processor 34 of patient programmer 62 may display theconditions via user interface 38 and wait for an input or response frompatient 12 or the user before entering the MRI safe operating mode.

In some examples, in processor 24 of AIMD 14 may be configured to beable to enter two or more MRI conditionally safe operating modes. Insome examples, processor 24 may be configured to enter a first MRIconditionally safe operating mode when MRI modality 54 operates using afirst set of operating parameters or comprises a first RF coil type, orwhen a MRI scan is utilized for a first portion of the body of patient12 (e.g., a head). Processor 24 then may be configured to enter a secondMRI conditionally safe operating mode when MRI modality operates using asecond set of operating parameters (e.g., a second magnetic fieldstrength) or comprises a second RF coil type, or when a MRI scan isutilized for a second portion of the body of patient 12 (e.g., a fullbody MRI scan).

In other examples, processor 24 may be configured to enter the first MRIconditionally safe operating mode when at least one condition forentering the second MRI conditionally safe operating mode is not met.For example, patient 12 may be requesting stimulation or monitoring or aphysiological parameter of patient 12 may indicate to processor 24 thatstimulation is required. Processor 24 then enter the first MRIconditionally safe operating mode, and processor 34 of programmer 62 maydisplay via user interface 38 a more restrictive set of conditions whichmust be complied with during the time that AIMD 14 is configured in theMRI conditionally safe operating mode. For example, the more restrictiveconditions may include more conservative operating parameters of MRIscanner 55, such as a lower maximum magnetic field. When all conditionsare met for entering the MRI safe operating mode, processor 24 may enterthe MRI safe operating mode, which may have a less restrictive set ofconditions which must be complied with during the time that AIMD 14 isconfigured in the MRI conditionally safe operating mode. For example,the less restrictive conditions may include less conservative operatingparameters of MRI scanner 55, such as a higher magnetic field.

In some examples, the technique may conclude with processor 34 ofpatient programmer 62 preparing MRI modality 54 for scanning patient 12(120). Such a step may not be performed by processor 34 of patientprogrammer 62 in all examples. However, preparing MRI modality 54 viaprocessor 34 of patient programmer 62 may further automate the procedureof determining MRI compatibility of AIMD 14 and preparing AIMD 14 andMRI modality 54 for an MRI scan of patient 12.

As shown in FIG. 4, processor 34 of patient programmer 62 and MRImodality 54 may be connected to a network 66 via which processor 34 maytransmit an instruction to MRI modality 54 to prepare for scanningpatient 12. Preparation of the MRI modality 54 for scanning may include,for example, scan parameter validation, e.g., setting or confirming MRIscan parameters according to which the MRI scanner 55 will scan patient12. The MRI scan parameters may include, for example, a magnetic fieldmagnitude and a gradient strength. A magnetic field that is too high maynot be suitable for a patient 12 having an AIMD 14 implanted in his orher body, as described above. Similarly, a gradient strength that is toolarge may not be suitable for a patient having an AIMD 14 implanted inhis or her body.

In some examples, the scan parameters determined by processor 34 andcommunicated via network 66 to MRI modality 54 may be verified by auser, such as a clinician or MRI technician. The user should confirmthat the MRI scan parameters adhere to the guidelines of the AIMD 14implanted in patient 12. In some examples, the user may consult aradiologist or a manufacturer of AIMD 14 for assistance in validatingthe MRI scan parameters. For example, the user may contact themanufacturer of AIMD 14 via a phone call or a website of themanufacturer.

The user may also validate that the RF coil of the MRI scanner 55 iscompatible with AIMD 14. For example, AIMD 14 may be compatible onlywith an MRI scanner 55 that include a single channel RF coil, and maynot be compatible with an MRI scanner 55 that includes a multiplechannel RF coil. As another example, a quadrature bird cage RF coil mayfunction in linear mode and cause AIMD 14 to be exposed to an excessivemagnetic field.

In some examples, the user may perform a test MRI scan, e.g., an MRIscan that is not performed on patient 12, to ensure proper functioningof the MRI RF coil. If the test scan fails to produce expected imagequality or indicates improper operation of the MRI RF coil, the MRIscanner 55 may not be suitable to scan patient 12, and furtherinvestigation may be required (90).

In some examples, the MRI scanner 55 may include an AIMD mode thatassures stringent internal limits on operation of the MRI scanner 55 toprevent AIMD 14 from being exposed to excessive magnetic fields.Processor 34 communicate an instruction to MRI modality 54 to configurethe MRI scanner 55 in the AIMD mode prior to scanning patient 12. Oncethe MRI scanner 55 is prepared for scanning (120), the user may initiatethe MRI scan of patient 12.

In some examples, a processor may implement a technique to make adetermination of compatibility between an AIMD 14 and a MRI modality 54which may include obtaining MRI compatibility information from anexternal data server (i.e., a data server separate from the computingdevice which includes the processor). Any of the computing devicesdescribed herein may include the processor, such as AIMD 14, externalprogrammer 20, patient information terminal 52, MRI modality 54, MRIcompatibility web server 68, MRI data server 58, or AIMD data server 60.In some examples, the external data server may include at least one ofpatient data archive 56, AIMD data server 60, or MRI data server 58. Theprocessor may access the external data server via network 66. In someexamples, the external data server may be located remotely from theprocessor, e.g., in a different physical location. In some examples, theprocessor may complement the MRI compatibility information obtained fromthe data server(s) with information obtained from additional sources,such as MRI compatibility web server 68, AIMD 14, external programmer20, MRI modality 54, or patient information terminal 52. As describedabove, the MRI compatibility information may include AIMD informationand/or MRI modality information. The processor then may utilize the MRIcompatibility in a manner similar to the techniques described herein,such as techniques described with reference to one or more of FIGS. 5-8.

The techniques described in this disclosure, including those attributedto various computing devices or other components of system 50, orvarious constituent components, may be implemented, at least in part, inhardware, software, firmware or any combination thereof. For example,various aspects of the techniques may be implemented within one or moreprocessors, including one or more microprocessors, digital signalprocessors (DSPs), application specific integrated circuits (ASICs),field programmable gate arrays (FPGAs), or any other equivalentintegrated or discrete logic circuitry, as well as any combinations ofsuch components, embodied in programmers, such as physician or patientprogrammers, AIMDs, web servers, data servers, information terminals, orother computing devices. The term “processor” or “processing circuitry”may generally refer to any of the foregoing logic circuitry, alone or incombination with other logic circuitry, or any other equivalentcircuitry.

Such hardware, software, and/or firmware may be implemented within thesame device or within separate devices to support the various operationsand functions described in this disclosure. In addition, any of thedescribed units, modules or components may be implemented together orseparately as discrete but interoperable logic devices. Depiction ofdifferent features as modules or units is intended to highlightdifferent functional aspects and does not necessarily imply that suchmodules or units must be realized by separate hardware or softwarecomponents. Rather, functionality associated with one or more modules orunits may be performed by separate hardware or software components, orintegrated within common or separate hardware or software components.

When implemented in software, the functionality ascribed to the systems,devices and techniques described in this disclosure may be embodied asinstructions on a computer-readable medium such as random access memory(RAM), read-only memory (ROM), non-volatile random access memory(NVRAM), electrically erasable programmable read-only memory (EEPROM),FLASH memory, magnetic data storage media, optical data storage media,or the like. The instructions may be executed to support one or moreaspects of the functionality described in this disclosure.

Many aspects of the disclosure have been described. Variousmodifications may be made without departing from the scope of theclaims. These and other examples are within the scope of the followingclaims.

What is claimed is:
 1. A system comprising a processor configured to:automatically obtain magnetic resonance imaging (MRI) compatibilityinformation relating to compatibility of an active implantable medicaldevice (AIMD) implantable in a patient with an MRI modality from atleast two information sources, wherein the at least two informationsources comprise at least one of a first information source associatedwith a patient programmer or a second information source associated withthe AIMD; automatically determine compatibility of the AIMD with the MRImodality based on the MRI compatibility information; and in response toa determination that the AIMD is incompatible with the MRI modality,output an indication that the AIMD is incompatible with the MRImodality, wherein the indication is configured to cause a MRI scan to berefused.
 2. The system of claim 1, further comprising the at least twoinformation sources.
 3. The system of claim 1, wherein one of the atleast two information sources comprises the first information sourceassociated with the patient programmer and another of the at least twoinformation sources comprises at least one of a third information sourceassociated with a patient information terminal, a fourth informationsource associated with a patient data archive, a fifth informationsource associated with an AIMD data server, a sixth information sourceassociated with an MRI data server, and the second information sourceassociated with the AIMD.
 4. The system of claim 1, wherein theprocessor is further configured to generate a notification indicatingwhether the AIMD is compatible with the MRI modality based on thedetermination.
 5. The system of claim 1, wherein the processor isfurther configured to archive in a patient data archive at least one ofthe MRI compatibility information and the determination of whether theAIMD is compatible with the MRI modality.
 6. The system of claim 1,further comprising the AIMD, and wherein the processor automaticallyinstructs the AIMD to enter an MRI conditionally safe operating mode. 7.The system of claim 1, further comprising an external programmer for theAIMD, wherein the processor, via the external programmer, prompts a userto configure the AIMD in an MRI conditionally safe operating mode. 8.The system of claim 1, further comprising a patient informationterminal, a data server, and an MRI compatibility web server, whereinone of the patient information terminal, the data server and the MRIcompatibility web server comprises the processor.
 9. The system of claim1, wherein the MRI compatibility information comprises an implantlocation of the AIMD, and wherein the processor is further configured toconfirm whether the implant location of the AIMD permits an MRI scan tobe performed by the MRI modality.
 10. A method comprising: automaticallyobtaining with a processor magnetic resonance imaging (MRI)compatibility information relating to compatibility of an activeimplantable medical device (AIMD) implantable in a patient with an MRImodality from at least two information sources, wherein the at least twoinformation sources comprise at least one of a first information sourceassociated with a patient programmer or a second information sourceassociated with the AIMD, wherein the patient programmer is configuredto communicate with the AIMD; automatically determining with theprocessor compatibility of the AIMD with the MRI modality based on theMRI compatibility information; and in response to a determination thatthe AIMD is incompatible with the MRI modality, outputting, with theprocessor, an indication that the AIMD is incompatible with the MRImodality, wherein the indication is configured to cause a MRI scan to berefused.
 11. The method of claim 10, wherein automatically obtainingwith the processor MRI compatibility information comprises automaticallyobtaining with the processor the MRI compatibility information from thefirst information source associated with the patient programmer and atleast one of a third information source associated with a patientinformation terminal, a fourth information source associated with apatient data archive, a fifth information source associated with an AIMDdata server, a sixth information source associated with an MRI dataserver, and the second information source associated with the AIMD. 12.The method of claim 10, further comprising automatically generating withthe processor a notification indicating whether the AIMD is compatiblewith the MRI modality based on the determination.
 13. The method ofclaim 10, further comprising automatically archiving in a patient dataarchive at least one of the MRI compatibility information and thedetermination of whether the AIMD is compatible with the MRI modality.14. The method of claim 10, further comprising automatically instructingthe AIMD to enter an MRI conditionally safe operating mode.
 15. Themethod of claim 10, further comprising prompting, via an externalprogrammer for the AIMD, a user to configure the AIMD in an MRIconditionally safe operating mode.
 16. The method of claim 10, whereinthe MRI compatibility information comprises an implant location of theAIMD, the method further comprising: confirming with the processorwhether the implant location of the AIMD permits an MRI scan to beperformed by the MRI modality.
 17. A computer-readable medium comprisinginstructions that cause a processor to: automatically obtain magneticresonance imaging (MRI) compatibility information relating tocompatibility of an active implantable medical device (AIMD) implantablein a patient with an MRI modality from at least two information sources,wherein the at least two information sources comprise at least one of afirst information source associated with a patient programmer or asecond information source associated with the AIMD, wherein the patientprogrammer is configured to communicate with the AIMD; automaticallydetermine compatibility of the AIMD with the MRI modality based on theMRI-compatibility information; and in response to a determination thatthe AIMD is incompatible with the MRI modality, output an indicationthat the AIMD is incompatible with the MRI modality, wherein theindication is configured to cause a MRI scan to be refused.
 18. Thecomputer-readable medium of claim 17, further comprising instructionsthat cause the processor to automatically generate a notificationindicating whether the AIMD is compatible with the MRI modality based onthe determination.
 19. The computer-readable medium of claim 17, furthercomprising instructions that cause the processor to automaticallyarchive in a patient data archive at least one of the MRI compatibilityinformation and the determination of whether the AIMD is compatible withthe MRI modality.
 20. The computer-readable medium of claim 17, furthercomprising instructions that cause the processor to automaticallyinstruct the AIMD to enter an MRI conditionally safe operating mode. 21.The computer-readable medium of claim 17, further comprisinginstructions that cause the processor to prompt, via an externalprogrammer for the AIMD, a user to configure the AIMD in an MRIconditionally safe operating mode.
 22. The computer-readable medium ofclaim 17, wherein the MRI compatibility information comprises an implantlocation of the AIMD, and the computer-readable medium further comprisesinstruction that cause the processor to: confirm whether the implantlocation of the AIMD permits an MRI scan to be performed by the MRImodality.
 23. A system comprising: means for automatically obtainingmagnetic resonance imaging (MRI) compatibility information relating tocompatibility of an active implantable medical device (AIMD) implantablein a patient with an MRI modality from at least two information sources,wherein the at least two information sources comprise at least one of afirst information source associated with a patient programmer or asecond information source associated with the AIMD, wherein the patientprogrammer is configured to communicate with the AIMD; means forautomatically determining compatibility of the AIMD with the MRImodality based on the MRI compatibility information; and means for, inresponse to a determination that the AIMD is incompatible with the MRImodality, outputting an indication that the AIMD is incompatible withthe MRI modality, wherein the indication is configured to cause a MRIscan to be refused.
 24. The system of claim 23, wherein the MRIcompatibility information comprises an implant location of the AIMD,further comprising: means for confirming whether the implant location ofthe AIMD permits an MRI scan to be performed by the MRI modality.